¿Cómo implementa su empresa su software?

Question

Actualmente estoy en un proyecto de investigación corto. La compañía en la que trabajo tiene un proceso de lanzamiento muy pesado que empeora a medida que pasa el tiempo. Estamos encontrando más y más problemas con cada lanzamiento, que está empezando a afectar gravemente nuestros horarios de entrega y la calidad de cada lanzamiento. Proporcionamos un gran producto SAAS que se implementa en Internet en una gran granja web. Nuestro proceso de implementación es manejado actualmente por un equipo dedicado, con una participación mínima del desarrollador. Principalmente somos una tienda .NET, sin embargo, también tenemos un par de componentes Java.

Estoy investigando cómo podríamos mejorar nuestro proceso de control de calidad y despliegue para reducir el desperdicio y llevar más procesos bajo la supervisión de nuestros equipos de desarrollo. Estoy interesado en saber cómo su empresa implementa sus productos (preferiblemente SAAS, pero no limitado a dichos productos) para la producción, así como el viaje a través de las pruebas en su camino hacia allí. Tengo curiosidad por saber qué ha funcionado y qué no, y estoy seguro de que muchos de ustedes tienen historias que contar.

EDITAR (RFC adicional):

Como he continuado mi investigación, me encontré con el concepto de "despliegue continuo", al parecer por primera vez por el equipo de la comunidad en línea 3d IMVU. Suena como un concepto intrigante, aunque quizás un poco complejo. Tengo curiosidad si alguien aquí en SO tiene alguna experiencia con el despliegue continuo? Particularmente con un proyecto grande y complejo que tiene muchas partes. No necesariamente tiene que implementarse continuamente en la producción ... para nuestras necesidades a corto plazo, solo miraríamos la implementación continua a los entornos internos de dev/qa/perftest. Si alguien ha implementado la implementación continua, también tengo curiosidad por saber cómo gestionó el esquema de la base de datos y los cambios/reversiones de datos.

Gracias!

Answer 1

Implementamos una solución SaaS de servicios financieros para el entorno en la nube de Amazon AWS. Nuestra solución es 100% Java, por lo que muchas de las herramientas no se aplican a usted, pero los conceptos deberían serlo.

En primer lugar, reducimos el número de sorpresas cuando llega el momento de hacer una versión ejecutando un proceso de integración continuo. Cada vez que un desarrollador revisa el código fuente, la solución completa se genera automáticamente y todas las pruebas de la unidad se ejecutan automáticamente. Las notificaciones de falla se envían por correo electrónico al desarrollador en cuestión y al líder del equipo.

AWS se basa en el concepto de máquinas virtuales. Aprovechamos esto al crear una imagen de máquina virtual (Amazon las llama AMI) que contiene la versión específica del sistema operativo y las aplicaciones (Java, DB, etc.) que deseamos. El proceso de compilación crea todos los artefactos desplegables y luego los copia en una instancia en ejecución basada en ese AMI. Es el mismo proceso para todos los entornos (PRUEBA, DEMO, PROD), excepto para un único proyecto de configuración que encapsula diferencias de versión (por ejemplo, cadenas de conexión).

QA prueba el resultado en el entorno de PRUEBA. Una vez que aprueban la versión, repetimos el proceso de compilación dirigido a PROD (utilizando exactamente las mismas revisiones de control de versión. Recuerde, la única diferencia entre cada entorno es un proyecto de configuración).

En ese punto, creamos una máquina virtual (instancia) que se ejecuta en la base AMI con la base de código PROD y la llamamos STAGING. STAGING pasa por una serie de pruebas de aceptación, tanto automáticas como manuales. Aquí está la parte realmente buena ... ahora, quemamos este entorno (base AMI más nueva versión de nuestra aplicación) en una nueva AMI (imagen de la máquina virtual). Luego creamos nuevas instancias en ejecución de nuestros servidores de aplicaciones basadas en esta nueva imagen, actualizamos el equilibrador de carga para apuntar a estas nuevas instancias y simplemente eliminamos las instancias antiguas. Esa es la belleza de usar máquinas virtuales (al menos, esa es una de las bellas).

Cada vez que necesitamos ajustar la capacidad (horas punta/días), creamos nuevas instancias de servidor de aplicaciones desde la misma AMI de producción y las registramos con el equilibrador de carga. Cuando finaliza el pico, simplemente los eliminamos de la rotación de balanceo de carga, luego eliminamos las instancias adicionales después de unos minutos (para permitir que se completen las sesiones existentes).

Answer 2

¿No está diciendo qué está causando los problemas con sus lanzamientos? Estábamos teniendo problemas porque los archivos incorrectos terminaban en nuestra compilación. Nuestra respuesta a esto fue construir una herramienta que nos diera control y visibilidad en todos los archivos de nuestra compilación. Here es una transmisión de la herramienta que creamos.

Answer 3

Descargo de responsabilidad: Puedo vender lo que he escrito, pero por ahora, es gratis (y no se ha lanzado oficialmente de todos modos).

Utilizamos un sistema que he escrito.

Funciona al integrarse con su control de fuente y el servidor de CI. Me permite asignar el código a SVN, esperar una compilación en el servidor de compilación y luego, a través de la interfaz de la aplicación, configurarlo para una compilación específica, confirmar a en control de fuente y luego, en los servidores, actualizará. Lo bonito es que puedes actualizar Asynch, por lo que todos los servidores obtendrán la nueva versión al mismo tiempo.

Es un poco más complicado que eso, y requiere una cierta forma de configuración, pero es realmente muy hermoso (en mi opinión muy sesgada) cuando está en acción. Dispárame un correo electrónico si quieres una versión gratis 'alpha' para jugar. Cualquier versión beta de este será gratis también.

- Editar:

proceso general:

1. Commit al tronco
2. Espere a que la acumulación de servidor de CI, de construcción es 'desnudo' (no configurado para cualquier servidor)
3. Implementar compilar, utilizando la herramienta ("dashy"), para probar el servidor
4. Prueba
5. Ser feliz con la prueba
6. Despliegue de construcción (build misma) para vivir servidores

Las fases "Despliegue" consiste en comprometerse con SVN, y luego el programa, también instalado en sus servidores web, se pone la acumulación de SVN.

Efectivamente, agrego un nuevo elemento de nivel "base" en su estructura SVN estándar. Normalmente tienen:

/trunk 
/braches 
/tags 

Con dashy, puedo añadir /releases

/trunk 
/braches 
/tags 
/releases 

Answer 4

Tenemos una solución SaaS y, básicamente, utilizar el mismo proceso (servidor de integración continua, scripts de implementación para la prueba de puesta en escena-producción) Eric arriba, pero lo implementamos en nuestra propia infraestructura usando scripts personalizados basados ​​en PSTools (http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx) para hacer todo el copiado a los nodos de la granja.

Para cada implementación evaluamos si es posible permitir que diferentes nodos tengan diferentes versiones de la aplicación (es decir.no hay riesgos de integridad de datos) o tenemos que desconectar la aplicación durante unos segundos para sincronizar todos los nodos (la aplicación tarda unos 20 segundos en volver a estar en línea, ya que solo hace frente a las aplicaciones, desde un nodo maestro) ; pero la clave es tener una configuración de proceso de implementación de "una sola clave".