Web Application Deployment ...Que estas usando ... ????

[Carlos A. Osoria]

Hola a todos

Ante todo, Feliz y prospero año para todos ... !! :D

Tengo un problemita por aca con el deployment de las aplicaciones web y servicios web.

Quisiera saber que tipo de soluciones estan usando ustedes.

Aca tenemos un sistema de deployment super arcaico que fue desarrollado hace como 4 o 5 años ya, funciona de la siguiente forma mas o menos.

- TFS Build and crea archivos zip (custom) que contiene los ficheros de applicacion y dos ficheros (web.config y manifest.config) que son templates para la configuracion.

- Estos archivos zip son copiados manualmente a cada servidor donde la app sera instalada 

- El administrador entonces entra en powershell y corre un commando que instalada y configura la applicacion segun el servidor en particular.

( este ultimo paso es super tedioso pues algunas applicaciones deben ser instalas hasta en 4 servers debido a load balancing, redundancia ) 

Este sistema de deployment es bastate rigido :( 

 - Los archivos zip tienes deben ser copiados en un directorio especifico en el server antes de instalarlos.

 - Las applicaciones deben ser instaladas bajo un directorio predeterminado en el server. 

 - La configuracion de parametros fuera de los normales (autenticacion, bindings) hay que hacerlo manualmente y los admin a veces cometen errores.

 - Application pool y sus parametros sufren de la misma historia. 

 

La herramienta tiene otras deficiencias que quizas no vale la pena mencionar. (Null Reference Exceptions, .....,  LOL !!! ) 

Me pregunto que herramientas (como por ejemplo Octupus Deploy) estan usando ustedes en sus deployments.

Hace como 3 meses atras empezamos un proceso para migrar y modernizar webapps y web services y esta herramienta de deployment no nos resuelve todos los problemas que tenemos.

Saludos a todos

Carlos 

--

Eng. Carlos A. Osoria.
carlos...@gmail.com

[Israel García]

Acá en Amadeus North America, en la oficina de Miami están en culeros... un powershell con miles de problemas que cuando me toca hacer el deployment a mi, a veces prefiero hacerlo manualmente antes de correr el script. 

Hace un par de meses cambiaron el jefe de desarrollo y afortunadamente el tipo aceptó cambiarse a un entorno  automatizado, en este caso Jenkins. Yo no he usado Octopus pero he leído resuelve problemas como el que tienes. 

He hecho ejercicios con Bamboo y está muy bueno. Al final si tienes cosas  customizadas como cambios a archivos de configuración, detener y arrancar servicios tienes que recurrir q a powershell o un script. Pero bueno al menos con estas herramientas tienes más seguridad y un reporte de lo que paso bien o no.

Suerte.

Israel

Sent from my iPhone

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Carlos A. Osoria]

Gracias Israel 

Jenkins lo use hace ya un tiempo, pero solo para la parte de CI ... 

Les dare una ojeada ....

Saludos

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Ernesto Freyre]

Ansible, Docker, Jenkins para empezar. Aunque en el mundo .net deben haber alternativas algunas de esta son bastante portables. 

La forma que he visto en los ultimos 3 años y 4 compañias es: Github commit hook => Jenkins (Circle-ci actualmente) => Auto Ansible deploy to dev stage, staging or prod, depending on the branch was committed.

Ernesto

[Erich]

Teamcity from JetBrains, CI & CD

Sent from my iPhone

[Ajadex Lopez]

Hola Carlos,

Hay 2 approaches que puedes usar que van a ser superior a lo que tienes ahora:

1- Configuration as Code o Infraestructure as Code (https://martinfowler.com/bliki/InfrastructureAsCode.html). Usando herramientas como Ansible, Puppet, Chef, etc. Tienes un DSL medio declarativo donde expresas lo que quieres y el server se encarga de recrear tus environments de esa manera.

2 - Usando Containers. Si usas .NET Core puedes usar Docker containers donde creas imagenes de tus microservicios con toda la configuración y lo único que haces es subir la imagen para el servidor de docker que tengas corriendo. Para manejar todas esas imágenes puedes usar Kubernetes, Docker Swarm, Mesos o Amazon ECS. Aquí puedes tener esos servidores de container corriendo en tu infraestructura o los puedes tener en el cloud como un servicio de los cloud vendors.

Para el orchestration desde build, test, staging and prod deployment puedes usar un CI Server y adaptarlo para que haga CD usando Rake, Powershell, MSBuild, Nant, etc. De tools para correr esto puedes usar TeamCity, Jenkins, Bamboo, Concourse. Nosotros migramos de TeamCity para Concourse porque es más fácil definir los pipelines en código en lugar de usar el UI. Cuando tienes muchos servicios escalar esta configuración es beneficioso. Además, los pipelines creados con Concourse son immutables, lo cual hace el deployment más seguro de que no falle al ser repeatable.

Saludos.

[Carlos A. Osoria]

Wonderful 

Gracias por todas las recomendaciones, me toca ahora echarle un vistazo a todas estas alternativas

Saludos

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

[Javier de Paula]

Carlos, 

Lo que dijo Ajadex+Freyre lo q no creo que tu estés en .NET Core. Así que tírate contra uno de los conocidos, Jenkins es el más seguro. Aunque si ya tienes experiencia con TeamCity, puedes empezar con TeamCity que es Free hasta 20 proyectos.

Estás haciendo ahora mismo la pregunta del millón, y el millón de respuestas. Con CIs está pasando lo q con Javascript… hay mil maneras de hacer lo mismo. Pero la realidad es q el mundo se está moviendo a Containerization, las VMs, los VmWares, VirtualBoxes se están desapareciendo. Containers es lo q se lleva.

La realidad es q containers te permite, tener environments prácticamente idénticos Locales y Producción. Bueno en este caso, voy a traer a colación Kubernetes que no es un CI pero si te manejaría los containers. 

Nada, yo creo que cualquier cosa que hagas te va a mejorar la cosa, pero si quieres estar en lo último de lo último, yo creo que Travis+Kubernetes (corriendo en Google AppEngine) estarías ahi toqueteando lo último de lo último.

Javi

Feliz Año Nuevo!

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.

[Carlos A. Osoria]

Muchas Gracias Ajadex 

Veo que en este tema de los "deployment" hay muchas mas opciones de las que pense, 

Tambien me parece que vamos a tener que tazar una estrategia desde donde estamos hasta donde queremos llegar, en estos momentos no tenemos containers ni nada por el estilo, creo tenedremos que implementar en fases, hasta llegar a una de las soluciones que describes.

Saludos

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

[Carlos A. Osoria]

Hola Javier 

Tienes razon, aun no estamos en .NET Core estamos en .NET 4.6, y 4.7 por aca, en esta empresa donde trabajo ahora las cosas avanzan tan rapido, ni siquiera tenemos la utilizacion de containers en el horizonte, creo que quizas sea porque no todos los servidores donde corren las applicaciones soportan containers. Tenemos aun applicaciones corriendo en Windows Server 2008 pa que tengas una idea, son applicaciones son de uso interno de la compannia pero tenemos que mantenerlas. 

Muchas gracias por las sugerencias mencionas algunos otros software que no habia oido antes. ;) 

Saludos

Carlos

[Karel Alfonso]

Hola Carlos,

  Adicionando mas a las respuestas a tu pregunta, estas son las recomendaciones dado el estado actual del delivery en tu compan~ia. Yo he tenido que implementar estas practicas en varios clientes sobre sistemas ya existente en produccion. Estos son los pasos que he aplicado:

0- Understand your operational environment and requirements:

• Is it cloud based, on-prem?
• How many servers? Dos?
• Deployment downtime ok? If so how much? (SLA driven)
• Deployment unit: machine image, OS executable, package, container, application binary?
• How long does it take as an average for the devs to complete functionality ready to deploy? If it’s too long (4 weeks) you should probably break down work in smaller pieces.
• What is the targeted release cadence? I know it might seem trivial that the more frequent the better but I’ve been on clients where they were happy with weekly or fortnightly deployments.
  
• More advance: staged deploy rollout?

1- Introduce poco a poco las practicas que los acerquen a un modelo de Continuous Integration: CI no es Jenkins, circle-ci, TeamCity, etc, etc. CI is the enablement of a single integration point where developers frequently share their code (https://trunkbaseddevelopment.com/continuous-integration/) and (https://www.martinfowler.com/articles/continuousIntegration.html)

- Automate build: code compilation, automated tests (unit, integration, if there are any), build artefact (could be one or many), publish build artefact to artefact repository (Nexus, DockerRegistry, etc: depends on the deployment unit)

• If there is no automated tests, bring this practice into the delivery process.

*** Note: This might not apply entirely in your case as your TFS build will be hopefully doing some of these steps.

2- Once you have a simple automated process that automates the build, in your case producing a ZIP file, then automate the deployment process:

• Best to drive it from the CI automation tool you use: most of them allow you to invoke scripts in different stages.
• Define environments that exercise the deployment process: Dev, Test, Staging, Production. I found the more mature the engineering practices the less environments you require (at Square we have Staging and Prod only).
• Make the CI automation tool automatically deploy upon  successful build to the first environment.
• Run a small number of smoke tests (functions, end to end) to make sure nothing is broken.

3- Build a deployment pipeline using the CI automation tool of your choice to then progress the build artefact through multiple environments till it reaches production (Staging and Production deployments should be manually driven(click button) but still automated)

This is a condensation of a roadmap that will put your company in a better position with more reliable delivery. All this is achievable no matter the OS, etc, but it’s time consuming, will require changes in your process and practices and support from management.

This is also the initial steps but there's tons of techniques and practices that will improve on the deployment process which others have mentioned: infrastructure as code: Terraform, CloudFormation, AzureTemplates, orchestrations tools like Ansible, Puppet, etc, centralised logging, monitoring, alerting

In one of my last experience I contributed to fixing a BI production system that took 2 days of running around, lengthy manual steps and late nights to deploy to prod. When we finished, it took 5 minutes to deploy using a deployment pipeline, CI practices (had to introduce tests), automated build, automated DB migration, automated AWS deployment. It took us 4 months or so and lots of patience and difficult conversations. Surprisingly we had lots of pushback from old-school “architects” that thought we were being “cool”. At the end we showed the benefits.

The process might be long and challenging, pick your battles as they say, but the outcome is rewarding.

Happy New Year,

Karel

Trunk Based Development

Trunk Based Development By paul-hammant A portal on this practice

The Practice of Cloud System Administration | Designing and Operating Large Distributed Systems

The Practice of Cloud System Administration | Designing and Operating Large...

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-c...@googlegroups.com.

[Carlos A. Osoria]

Hola Karel 

Muchas gracias por la detallada respuesta, de modo que tendremos que implementar estas practicas y estrategias en fases. 

Para nosotros todo tiene que funcionar On-Premises debido a restricciones del gobierno y los datos que manejamos. Algunas de las soluciones que fueron mencionadas al parecer solo se pueden implementar desde el cloud. 

El tiempo que toma poner nueva funcionalidad en produccion varia de dos semanas hasta 3 meses, en dependencia del sistema y la funcionalidad. En este punto tendremos que iterar para llegar a un consenso. Algunos equipos llevan annos trabajando en iteraciones que tardan 3 meses. Y cambiar este estilo les va a ser chocante. 

Tambien algo que esta complicado es la inter-dependencia de los sistemas :( tenemos bastante "temporal-coupling" por aca, recientemente empezamos a usar conceptos de messaging y event driven architectures para aliviar un poco las dependencias. 

Muchas gracias otra vez a todos por la magnifica informacion. 

Saludos

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

---
Has recibido este mensaje porque estás suscrito al grupo "Improve your code" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a improve-your-code+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.