Herramientas para ayudar a gestionar el proceso de promoción de aplicaciones en un entorno empresarial.

Question

Tengo curiosidad sobre cómo otros manejan la promoción de código de DEV a TEST a PROD dentro de una empresa.

¿Qué herramientas o procesos utiliza para administrar el lado de los criterios de entrada / salida de burocracia?

Mi organización actual está medio atascada entre algunas funcionalidades de tipo de formularios en línea personalizados y dependencias basadas en papel para enviar documentos, obtener aprobaciones y revisiones.

Todo esto se deja en manos de los gerentes de proyecto para realizar un seguimiento de lo que se ha enviado, aprobado, revisado y asesorado a la gerencia si hay obstáculos que pueden necesitar aprobación para ser "pasados ??por alto". antes de que una aplicación pueda promoverse al siguiente entorno.

Una aplicación basada en navegador sería ideal ... entonces, ¿qué hay ahí fuera? muéstrame que tu googlefu es mejor que el mío.

Answer 1

Es difícil encontrar uno que sea bueno a través de Google. Existe una gran variedad de herramientas para la gestión de problemas, por lo que mencionaré lo que usamos y lo que nos gustaría usar.

Actualmente utilizamos productos serena. Han funcionado bien para nosotros en el pasado. Team Track es nuestra gestión de problemas y maneja el ciclo de vida de cualquier problema en el que trabajemos. Version Manager es nuestro control de origen y tiene la función de implementar grupos promocionales como DEV TEST Y PROD. Usamos DEV, TSTAGE, TEST, PSTAGE y PROD para indicar el movimiento de uno a otro, pero es casi lo mismo. Los dos productos se integran muy bien para que la fuente asociada con los problemas esté vinculada, pero no tenemos una configuración de proceso de compilación en este entorno. Es caro, pero funciona bien.

Estamos buscando pasar a un sistema más común usando Jira para la gestión de problemas, Subversion para el control de fuente, Fisheye para vincular los dos y Cruise Control para la gestión de compilación. Esto es menos costoso, totaliza unos pocos miles para una licencia de empresa y ofrece las mismas características, pero con la ventaja adicional de SVN, que es una versión de código muy agradable mangager.

Espero que eso ayude.

Answer 2

Hay algunos escenarios diferentes que he experimentado a lo largo de los años:

Dev - > Prueba: por lo general, hay una fecha de congelación de código que detiene el trabajo en nuevas funciones y obtiene un entorno de prueba del código que ha sido etiquetado / etiquetado / archivado que se construye. Esto luego se copia en las máquinas y las pruebas van bien. Esto también suele ser el menos detallado de cualquier empuje.

Test- > Prod: Esto requiere el pequeño cambio que la producción tiene que bajar, lo que puede significar que un '' se fue de pesca '' la página sube o IIS no tiene ningún sitio en ejecución y el código se copia nuevamente. Hay casos especiales en los que un equilibrador de carga puede actuar como un interruptor para que la promoción suceda y ninguno de los clientes experimente ningún tiempo de inactividad ya que los del servidor anterior se moverán una vez que finalice su sesión.

Para profundizar en esa idea del interruptor, la configuración es tener 2 servidores potencialmente activos con un solo servidor que acepta que el equilibrador de carga solo envíe todo el tráfico a una máquina que se puede cambiar cuando el otro servidor tiene el código actualizado ir a vivir.

También puede haber un entorno de preparación que se encuentre entre la prueba y la producción, donde el proceso es similar en términos de que hay una fecha establecida cuando se realiza la promoción.

Donde solía trabajar habría días de fusión en los que un desarrollador pasara la mayor parte del día en Perforce fusionando código para poder promocionarlo de un entorno a otro.

Ahora hay un par de casos en los que esto no se usa:

" Hotfixes " o "Parches calientes" ocurriría donde solía trabajar y, en este caso, los archivos específicos se copiaron en los entornos de preparación y producción por sí solo, ya que el cambio de código tuvo que entrar en Producción lo antes posible ya que algo se rompió en la producción o algo nuevo que tenía que hacerse eso lleva 2 minutos se hace. En este caso, el cambio de código que se introdujo tuvo que revisarse y aprobarse antes de salir.

Esos son los diferentes enfoques que he visto utilizar, donde generalmente hay horarios y cronogramas que potencialmente tienen que cambiarse o recursos adicionales para hacer una cita difícil, como si una conferencia es un fin de semana en particular que tal y tal está listo para eso.

Por supuesto, en algunos lugares ha habido, "Oh, ¿eso se rompió? Déjame ver ... '' y unos minutos después, "No, veo que no está roto para mí". donde alguien cambió las cosas sin pedir permiso o algo donde una compañía todavía tiene lo que llaman "programación vaquera".

Otro punto es la escala del lanzamiento: 1) Diminuto: este es el caso en el que una página web sube para que el usuario X pueda hacer Y.

2) Pequeño: un puñado de archivos que no es realmente complicado pero que no es exactamente trivial.

3) Medio: cuando pasar de un entorno a otro requiere cambiar un montón de archivos y generalmente tiene scripts para mover.

4) Grande: donde hay promociones programadas y se pregunta a varios desarrolladores quién está tomando qué turnos cuando se realiza la transmisión en vivo. Tuve esto en un caso en el que había que realizar una migración de datos además de la publicación de algunos nuevos sitios de comercio electrónico.

5) Mammoth: donde todo es nuevo, incluida la forma en que se usaría. Creo que nunca he visto uno de este tamaño, pero imagino que Microsoft o Google tendrían versiones de este tamaño.

En algún lugar de ese espectro, la mayoría de los lanzamientos caen y, por lo tanto, la cantidad de planificación y preparación puede variar bastante y no olvidemos que el cumplimiento normativo puede ser su propio dolor al hacer algunas cosas.