¿Cómo es el comité/proceso de control de cambio sus pegas?

Nosotros usamos giltab self hosted, para pasar a produccion se crea un MR, dicho MR gatilla un pipeline automatico de test, en estos test se trae master a la branch de la feature nueva, para asegurarnos que el codigo funciona, una vez que pasa los test alguien "aprueba el MR", cuando se decide hacer "releease" alguine mergea los MR contra master y esto a su vez gatilla un nuevo pipeline que genera la imagen docker nueva y hace release de la misma a produccion.

Si pasamos una bomba a produccion siempre podemos hacer rollback a la imagen docker anterior SI y SOLO SI no hay migraciones troll de la db entre medio.

Tengo la impresión que trabajamos en la misma área JAJA. Acaso área banca bursátil de chile?
Yo me pregunto de qué sirve tener células de desarrollo ágil, scrum, daily y sprints si al momento de las liberaciones a producción se sigue chocando con el modelo cascada y el comité culiao de viejos vinagres rechazando todo porque les da miedo X weá.

Cada vez más empresas establecen procesos de gestión de cambio diferenciados para infraestructura/apps legadas (donde se basan en la práctica de habilitación de cambios de ITIL) y para aplicaciones de negocio "modernas" (donde siguen prácticas ágiles y uso de herramientas de apoyo CI/CD en la integración y liberación de los componentes).

El problema está cuando hay cambios que involucran infra y software a la vez. En mi experiencia, empresas con controles muy estrictos (por SOX, por ISO 20000, por COBIT) toman ITIL como gran paraguas de la gestión de los cambios y los equipos ágiles se tienen que acomodar (lo que claramente no es fácil, dadas las brechas generacionales entre los equipos de Dev (más jóvenes y más tolerantes al riesgo) que los equipos de Ops y Producción (típicamente de mayor edad y con mayor aversión al riesgo de tocar cosas sin la debida planificación y plan de marcha atrás)).

Independiente de lo anterior, si una sesión de CAB se toma 5 horas es un claro indicador de ineficiencia ya que podría ocurrir que:

- Se utiliza parte de la sesión para revisar la documentación del cambio (cuando ya debió ser leída por todos los miembros del comité, la idea es aprovechar el tiempo para discutir el impacto y no para ponerse a leer el cambio).
- El solicitante del cambio no lleva todos los argumentos a la sesión o se pone a buscar documentación complementaria en el momento.
- Entran en discusiones filosóficas sobre si el huevo o la gallina es primero (qué otros cambios hacen falta para hacer aquel que se está presentando) . El rol del coordinador del CAB es clave para dirigir la sesión.
- No han consensuado una cantidad adecuada de cambios a revisar en cada sesión.
- A lo mejor aprovechan para revisar cambios de emergencia, lo que es responsabilidad de otro comité (ECAB).

Disclaimer: Mi opinión está fundamentada desde la vereda del proveedor, uno de mis ámbitos de especialidad es gestión de cambios y he implementado la práctica (así como herramientas de apoyo TI) en no pocas empresas de la región.


Enviado desde mi SM-S901E mediante Tapatalk

un try-catch y que sea lo que dios quiera

Una vez trabajé en una empresa grande, donde bue... el control de versiones era un docstring para cada package y procedimiento en oracle con comentarios de que hizo cada persona y porque al estilo twitter (poco mas de 80 caracteres).

Luego, para el control de cambios, había que llenar un formulario de 1 a 2 planas, en word que tenía automatizadas varias cosas, pero que te lo rechazaban hasta por un tilde.

Ésto no era la peor parte. Las reuniones no eran para acordar cosas, si nó para penquearse al jefe/dueño de la empresa apalancada que prestaba servicios a la empresa grande por cada cosa que se hacía mal.

En general se pasaban varias pifeas grosas por hacer procedimientos del tipo search & replace en los archivos fuentes que almacenaban tooooodo el package, o todooodos los packages para cada subfilial.

El solo hecho de mencionar un respaldo, o una herramienta para control de versiones me acarreó un mal rato con el dueño de la empresa apalancada.

0 reuniones para todo, el tipo éste hacía reuniones con la gente de arriba solamente para tratar temas de platas y nuevos proyectos. Tampoco habían procedimientos.

Curioso que siendo los reportes core de una de las empresas que surte energía en la quinta región, admita un apitutado con una consultora que funcionara tan mediocremente de forma interna.

Mala exp, dure meses y salte por mejor sueldo y un ambiente laboral mas decente.

freishner dijo:

Una vez trabajé en una empresa grande, donde bue... el control de versiones era un docstring para cada package y procedimiento en oracle con comentarios de que hizo cada persona y porque al estilo twitter (poco mas de 80 caracteres).

Luego, para el control de cambios, había que llenar un formulario de 1 a 2 planas, en word que tenía automatizadas varias cosas, pero que te lo rechazaban hasta por un tilde.

Ésto no era la peor parte. Las reuniones no eran para acordar cosas, si nó para penquearse al jefe/dueño de la empresa apalancada que prestaba servicios a la empresa grande por cada cosa que se hacía mal.

En general se pasaban varias pifeas grosas por hacer procedimientos del tipo search & replace en los archivos fuentes que almacenaban tooooodo el package, o todooodos los packages para cada subfilial.

El solo hecho de mencionar un respaldo, o una herramienta para control de versiones me acarreó un mal rato con el dueño de la empresa apalancada.

0 reuniones para todo, el tipo éste hacía reuniones con la gente de arriba solamente para tratar temas de platas y nuevos proyectos. Tampoco habían procedimientos.

Curioso que siendo los reportes core de una de las empresas que surte energía en la quinta región, admita un apitutado con una consultora que funcionara tan mediocremente de forma interna.

Mala exp, dure meses y salte por mejor sueldo y un ambiente laboral mas decente.

Haz clic para expandir...

Acaso la empresa que compraron los chinos que comienza con chil y termina con quinta?