Mejoras en el proceso de liberación

Question

El proceso de creación de una nueva construcción y su lanzamiento a producción es un paso crítico en el SDLC, pero a menudo se deja como una ocurrencia tardía y varía mucho de una empresa a la siguiente.

Espero que las personas compartan las mejoras que han realizado en este proceso en su organización para que todos podamos tomar medidas para 'reducir el dolor'.

Entonces, la pregunta es, especifique una parte dolorosa/que consume mucho tiempo de su proceso de lanzamiento y ¿qué hizo para mejorarla?

Mi ejemplo: en un empleador anterior, todos los desarrolladores realizaron cambios de base de datos en una base de datos de desarrollo común. Luego, cuando llegó el momento del lanzamiento, utilizamos SQL Compare de Redgate para generar un script enorme a partir de las diferencias entre las bases de datos Dev y QA.

Esto funciona razonablemente bien, pero los problemas con este enfoque son: -

1. todos los cambios en la base de datos Dev están incluidos, algunos de los cuales todavía pueden ser 'obras en curso'.
2. A veces los desarrolladores realizaron cambios conflictivos (que no se notaron hasta que la versión estuvo en producción)
3. Fue un proceso lento y manual para crear y validar la secuencia de comandos (validar quiero decir, tratar de eliminar problemas como el problema 1 y 2).
4. Cuando hubo problemas con el script (por ejemplo, el orden en que se ejecutaron las cosas, como crear un registro que se basa en un registro de clave externa que está en el script pero aún no se ejecutó) tardó un tiempo en "modificarlo" funcionó sin problemas.
5. No es un escenario ideal para la integración continua.

Así que la solución era: -

1. hacer cumplir una política de todos los cambios en la base de datos debe ser un guión.
2. Una convención de nomenclatura era importante para garantizar el correcto orden de ejecución de los scripts.
3. Crear/Usar una herramienta para ejecutar los scripts en el momento del lanzamiento.
4. desarrolladores tenían su propia copia de la base de datos se desarrollan en contra (lo que no hubo más 'pisar los demás dedos de los pies')

El siguiente lanzamiento después de que empezamos este proceso fue mucho más rápido con menos problemas, de hecho los únicos problemas encontrados se debieron a que la gente "rompió las reglas", por ejemplo, no crear un guión.

Una vez que se solucionaron los problemas con la liberación de QA, llegó el momento de lanzar a producción y fue muy sencillo.

Aplicamos algunos otros cambios (como la introducción de CI) pero este fue el más significativo, en general redujimos el tiempo de liberación de alrededor de 3 horas a un máximo de 10-15 minutos.

Answer 1

automatizar su proceso de liberación dondequiera que sea posible.

Como han insinuado otros, use diferentes niveles de "profundidad" de compilación. Por ejemplo, una compilación de desarrollador podría hacer todos los archivos binarios para ejecutar su producto en la máquina de desarrollo, directamente desde el repositorio, mientras que la compilación de un instalador podría ensamblar todo para su instalación en una máquina nueva.

Esto podría incluir

• binarios,
• JAR/archives guerra,
• archivos de configuración por defecto,
• scripts de instalación del esquema de base de datos,
• scripts de migración de base de datos,
configuración
• OS scripts,
• páginas de hombre/hlp,
• documentación HTML,
• documentación en formato PDF

y así sucesivamente. La compilación del instalador puede rellenar todo esto en un paquete instalable (InstallShield, ZIP, RPM o lo que sea) e incluso crear CD ISO para la distribución física.

El resultado de la compilación del instalador es lo que normalmente se entrega al departamento de pruebas. Lo que no está incluido en el paquete de instalación (parche en la parte superior de la instalación ...) es un error. Desafíe a sus desarrolladores a entregar un procedimiento de instalación sin fallas.

Answer 2

Estructura automatizada de un solo paso. El script de compilación de ant edita todos los archivos de configuración del instalador, los archivos de programa que deben cambiarse (versiones) y luego compilar. No se requiere intervención.

Todavía hay un script ejecutado para generar los instaladores cuando está listo, pero lo eliminaremos.

La obra de arte del CD está versionada manualmente; eso también se ha solucionado

Answer 3

Hemos hecho algunas cosas durante el año pasado para mejorar nuestro proceso de construcción.

1. Completamente automatizada y completa compilación. Siempre hemos tenido una "compilación" nocturna, pero descubrimos que hay diferentes definiciones para lo que constituye una compilación. Algunos lo considerarían compilar, generalmente las personas incluyen pruebas unitarias y, a veces, otras cosas. Aclaramos internamente que nuestra versión automatizada literalmente hace todo lo necesario para pasar del control de origen a lo que entregamos al cliente. Cuanto más automaticemos varias partes, mejor será el proceso y menos tendremos que hacerlo manualmente cuando sea el momento de lanzarlo (y menos preocupaciones por olvidar algo). Por ejemplo, nuestra versión de compilación lo sella todo con el número de revisión svn, compila las diversas partes de la aplicación en algunos idiomas diferentes, ejecuta pruebas unitarias, copia las salidas de compilación a los directorios apropiados para crear nuestro instalador, crea el instalador real, copia el instalador a nuestra red de prueba, ejecuta el instalador en las máquinas de prueba y verifica que la nueva versión se haya instalado correctamente.

2. Demora entre el código completo y la liberación. Con el tiempo, hemos aumentado gradualmente la cantidad de demoras entre cuando finalizamos la codificación de un lanzamiento en particular y cuando ese lanzamiento llega a los clientes. Esto proporciona más tiempo dedicado para que los probadores prueben un producto que no cambia mucho y produce lanzamientos de producción más estables. La rama/fusión del control de la fuente es muy importante aquí, por lo que el equipo de desarrollo puede trabajar en la próxima versión, mientras que los verificadores todavía están trabajando en la última versión.

3. Sucursal. Una vez que hemos ramificado nuestro código para crear una rama de liberación y luego continuamos trabajando en la troncal para la siguiente versión, asignamos un único propietario de la sucursal de liberación rotativa que es responsable de verificar todas las correcciones aplicadas a la sucursal. Todos los registros, independientemente del tamaño, deben ser revisados ​​por dos desarrolladores.

Answer 4

ya Estábamos usando TeamCity (una excelente herramienta de integración continua) a hacer todo lo construye, que incluyó pruebas de unidad. Había tres grandes mejoras fueron mencionar:

1) Kit de instalación y de un solo clic UAT implementaciones

envasamos nuestra aplicación como un kit de instalación utilizando NSIS (no un MSI, que era mucho más complicado y innecesario para nuestras necesidades). Este kit de instalación hizo todo lo necesario, como detener IIS, copiar los archivos, colocar los archivos de configuración en los lugares correctos, reiniciar IIS, etc. Luego creamos una configuración de compilación de TeamCity que ejecutó ese kit de instalación de forma remota en el servidor de prueba utilizando psexec.

Esto permitió a nuestros evaluadores realizar las implementaciones de UAT, siempre que no contuvieran cambios en la base de datos, pero eran mucho más raros que los cambios de código.

Las implementaciones de producción fueron, por supuesto, más complicadas y no pudimos automatizarlas tanto, pero aún utilizamos el mismo kit de instalación, lo que ayudó a garantizar la coherencia entre UAT y la producción. Si faltaba algo o no se copiaba en el lugar correcto, generalmente se recogía en UAT.

2) La automatización de las implementaciones de bases de datos

Implementación de cambios de base de datos fue un gran problema también.Ya estábamos creando secuencias de comandos para todos los cambios en la base de datos, pero todavía había problemas para saber qué secuencias de comandos ya se habían ejecutado y cuáles todavía se necesitaban ejecutar y en qué orden. Miramos varias herramientas para esto, pero terminamos rodando las nuestras.

Los scripts de BD se organizaron en una estructura de directorios por el número de versión. Además de los scripts, los desarrolladores debían agregar el nombre de archivo de un script a un archivo de texto, un nombre de archivo por línea, que especificaba el orden correcto. Escribimos una herramienta de línea de comandos que procesó este archivo y ejecutó los scripts contra un DB determinado. También registró qué scripts había ejecutado (y cuándo) en una tabla especial en el DB y la próxima vez no los ejecutó nuevamente. Esto significa que un desarrollador podría simplemente agregar un script DB, agregar su nombre al archivo de texto y ejecutar la herramienta contra el DB de UAT sin correr preguntando a otros qué secuencias de comandos ejecutaron por última vez. Usamos la misma herramienta en producción, pero por supuesto solo se ejecutó una vez por lanzamiento.

El paso adicional que realmente hizo que esto funcione bien es ejecutar el despliegue de DB como parte de la compilación. Nuestras pruebas unitarias corrieron contra una base de datos real (una muy pequeña, con datos mínimos). El script de construcción restauraría una copia de seguridad del DB de la versión anterior y luego ejecutaría todos los scripts para la versión actual y tomaría una nueva copia de seguridad. (En la práctica, fue un poco más complicado, porque también teníamos parches y la copia de seguridad solo se realizó para versiones completas, pero la herramienta fue lo suficientemente inteligente como para manejar eso). Esto aseguró que los scripts DB se probaron juntos en cada compilar y si los desarrolladores realizaran cambios de esquema conflictivos, se recogerían rápidamente.

Los únicos pasos manuales fueron en tiempo de liberación: aumentamos el número de versión en el servidor de compilación y copiamos la copia de seguridad "DB actual" para que sea la copia de seguridad de "última versión". Aparte de eso, ya no teníamos que preocuparnos por la base de datos utilizada por la compilación. La base de datos UAT todavía tenía que restaurarse de vez en cuando a partir de una copia de seguridad (por ejemplo, ya que el sistema no podía deshacer los cambios para un script DB borrado), pero eso era bastante raro.

3) La ramificación de un comunicado de

Suena básico y casi no vale la pena mencionar, sin embargo, no estaban haciendo esto para empezar. La fusión de los cambios puede ser ciertamente dolorosa, ¡pero no tanto como tener una única base de código para el lanzamiento de hoy y el mes próximo! También obtuvimos a la persona que realizó la mayor cantidad de cambios en las ramas de publicación para realizar la fusión, lo que sirvió para recordarles a todos que mantengan sus compromisos de la rama de publicación al mínimo absoluto.

Answer 5

De acuerdo con los comentarios anteriores.

Esto es lo que ha evolucionado donde trabajo. Este proceso actual ha eliminado los "errores" que ha descrito en su pregunta.

Utilizamos ant para extraer el código de svn (por versión de etiqueta) y obtener dependencias y compilar el proyecto (y, a veces, también para implementarlo).

Se utiliza la misma secuencia de comandos ant (parámetros pasados) para cada env (dev, integración, prueba, prod).

proceso Proyecto

• La captura de requisitos que los usuarios 'historias' (ayuda a evitar las objeciones sobre una interpretación de un requisito, cuando expresarse como una interacción del usuario significativa con el producto)
• tras un principios ágiles para que cada iteración del proyecto (2 semanas) resulte en una demostración de la funcionalidad actual y un producto liberable, si es limitado,
• gestione las historias de publicación a lo largo del proyecto para comprender qué está dentro y fuera del alcance (y evitar confusiones correcciones Nute)
• (repetición de la respuesta anterior) congelación del código, entonces sólo de prueba (no hay características añadidas)

proceso Dev

• unidad de prueba
• checkins código
• programado construcciones automáticas (control de crucero, por ejemplo)
• completar una compilación/implementación en un entorno de integración, y carreras fuman prueba
• etiqueta del código y se comunican al equipo (para la experimentación y la liberación de planificación)

proceso de prueba

• ensayos de funcionamiento (selenio, por ejemplo)
• la ejecución de planes de prueba y escenarios funcionales

Una persona maneja el proceso de liberación, y ens ures todos cumplen. Además, todos los lanzamientos se revisan una semana antes del lanzamiento.Las versiones solo son aprobados si hay:

Proceso de Liberación

• Aprobar liberación para una fecha específica/hora
• plan de lanzamiento de revisión/rollback
hormiga
• carrera con 'despliegue de producción' parámetro
• ejecutar tareas de DB (si las hay) (también, estas secuencias de comandos pueden ser versionadas y etiquetadas para producción)
• ejecutar otros cambios del sistema/c onfigs
• comunicar los cambios

Answer 6

No sé SDLC o en la práctica, pero para mí, estas herramientas han sido indispensables en la consecución de comunicados de lisas:

• Maven para construir, con Nexus gerente repositorio local
• Hudson para integración continua, versiones de lanzamiento, etiquetado SCM y promoción de construcción
• Sonar para métricas de calidad.
• base de datos de seguimiento de los cambios en el esquema de desarrollo db y la gestión de cambios a control de calidad y liberan a través de DbMaintain y LiquiBase

Answer 7

En un proyecto donde trabajo, utilizamos las migraciones de Doctrine (PHP ORM) para actualizar y degradar la base de datos.Tuvimos todo tipo de problemas ya que los modelos generados ya no coinciden con el esquema de la base de datos, lo que hace que las migraciones fallen completamente a mitad de camino.

Al final, decidimos escribir nuestra propia versión súper básica de la misma cosa, nada sofisticado, solo arriba y abajo que ejecutan SQL. De todos modos funcionó muy bien (hasta ahora, toque madera). Aunque reinventamos ligeramente la rueda al escribir la nuestra, el hecho de que la atención se centrara en mantenerlo simple significaba que teníamos muchos menos problemas. Ahora un lanzamiento es muy fácil.

Supongo que la moraleja de la historia aquí es que a veces está bien reinventar la rueda algunas veces, siempre que lo haga por una buena razón.