Como ingeniero de DevOps con experiencia en operaciones, habrá pasado de construir e implementar servidores y software manualmente a crear scripts para la instalación de software en sus servidores con BASH, PowerShell, Python, etc. Después de un tiempo, se dará cuenta de cómo Los scripts geniales son y comienzan a explorar formas más sofisticadas para automatizar la implementación .
Eventualmente, se habría decidido por un Chef, Puppet, Ansible u otra herramienta de administración de configuración para ayudar a administrar el estado de su flota de sistemas. A medida que maduraron sus habilidades con la automatización de la implementación de aplicaciones y la administración del sistema, junto con sus herramientas, más recientemente se mudó al ámbito de ' Infraestructura como código ' y lo usó no solo para automatizar la implementación de software sino también la infraestructura y los entornos requeridos para conducir el software durante el cambio del negocio a la nube.
Ahora estás cocinando con gas. Con el tiempo, se le han presentado los beneficios del uso de herramientas centradas en el desarrollador, como el control de código fuente, para administrar los módulos, recetas y plantillas que conforman su arsenal de herramientas de implementación y administración.
Cuando ingresó al equipo de DevOps , estuvo expuesto al ciclo de vida de desarrollo de software y al concepto de integración continua . ¡Vaya, esos desarrolladores lanzaron cambios rápidamente y para mantenerte al día te encontraste trabajando más estrechamente con los desarrolladores! Experimentó la urgencia puesta en el equipo de desarrollo para cambiar las cosas TODO EL TIEMPO, lo que contradice el viejo paradigma operativo de " si no está roto, no lo arregle ". No más alardear sobre el tiempo de actividad del sistema, ya está en la infraestructura desechable .
Notó que el cambio a DevOps fue más que trabajar con los desarrolladores o usar nuevas herramientas y técnicas , pero hubo un cambio cultural distinto en el equipo, uno que impregnaba la organización en general. Usted estaba trabajando como un equipo muy unido con responsabilidades compartidas , herramientas y objetivos compartidos .
Tomó sus habilidades en la implementación automatizada y las incorporó a la tubería " CICD " que está siendo orquestada por un " servidor de integración continua " como Jenkins , Bamboo o Code Pipeline . Ahora, cuando los desarrolladores introducen un nuevo código, sus scripts, herramientas y plantillas presentan nuevos entornos bajo demanda, activan marcos de prueba para hacer lo suyo y destruyen los entornos de preproducción después de que se encienden las luces verdes en el lanzamiento, adhiriéndose a la ideas de " entrega continua ".
A medida que el nuevo código se abre paso a través de las etapas de CICD, usted, los desarrolladores y la empresa confían en que la actualización no se romperá cuando se lance a producción. Hay un camino por recorrer antes de que el equipo llegue a un " despliegue continuo ", aún debe decidirse por los puntos más finos de automatizar la capacidad de despliegue azul / verde , y la decisión es principalmente de negocios. Por el momento, está contento de que la cantidad de llamadas a las 3 a. M. Haya disminuido y la disminución de sev-1 y sev-2.
Incluso si obtienes un sev-1, ya no estás tirando todas las noches con los gerentes respirando por tu espalda: puedes lanzar fácilmente la versión anterior a través de la tubería CICD y volver a poner el sistema en línea en poco tiempo. El negocio ha notado que la estabilidad de los sistemas de TI ha mejorado a pesar de la velocidad de los cambios .
Te maravilla la forma en que administras los recursos necesarios para impulsar el software en tu negocio, especialmente cuando piensas en cómo solía ser y la cantidad de sangre que dejaste en los rieles en el centro de datos ...
