Planificación de Integración Continua y Rollout de Software
Contenido del curso
¿Alguna vez te has preguntado por qué tú no tenías la reacción del "Me importa" en Facebook pero tus otros amigos sí? Bien, aquí tienes por qué, el plan de integración continua comienza a hacer el despliegue en producción paso por paso. . Aquí es donde vemos lo que comenté en la clase anterior, el uso de git, GitHub y sus branches, que de nuevo, esto está bien explicado en esta clase: . https://platzi.com/clases/1557-git-github/19955-flujo-de-trabajo-profesional-haciendo-merge-de-ram/ . Algo que me parece curioso son los tags, si los conocía, pero se me hacía más lógico tener un branch exclusivo para producción, y que ese branch sea master.
Los tags nos permiten también rápidamente volver a la versión que NO fallaba y revertir los cambios con más agilidad
Me parece genial la manera en que citas a esa clase. Para todos, me incluyo, lo asemejaron al versionamiento pero en código, más no de aplicación.
Siendo realistas, el generar cambios en un código con muchos colaboradores genera mucho caos, por eso adopte la forma de contribución de Angular:
<type>(<scope>): <short summary> │ │ │ │ │ └─⫸ Summary in present tense. Not capitalized. No period at the end. │ │ │ └─⫸ Commit Scope: animations|bazel|benchpress|common|compiler|compiler-cli|core| │ elements|forms|http|language-service|localize|platform-browser| │ platform-browser-dynamic|platform-server|router|service-worker| │ upgrade|zone.js|packaging|changelog|dev-infra|docs-infra|migrations| │ ngcc|ve │ └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test
The `<type>` and `<summary>` fields are mandatory, the `(<scope>)` field is optional. ##### Type Must be one of the following: * **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) * **ci**: Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs) * **docs**: Documentation only changes * **feat**: A new feature * **fix**: A bug fix * **perf**: A code change that improves performance * **refactor**: A code change that neither fixes a bug nor adds a feature * **test**: Adding missing tests or correcting existing tests
Les recomiendo mucho revisar gitflow, que es la manera en que trabajamos en la empresa que me encuentro. Me parece útil y creo que tiene las ramas necesarias para tener orden en el repositorio, a continuación relaciono una imagen del flujo:
Hola Carlos! Que gran aporte! Gracias
Como aporte en los deployments por lo general se utilizan estrategias de deployments como canary, blue/green, rolling deployment para realizar todo lo que el se referia de liberas la version a X cantidad de Usuario o Zonas, etc. Les dejo un enlace donde pueden leer mas y tener una idea mas completa de las estrategias de deployment.
Algo que aún no entiendo es cómo divides tú a qué áreas desplegarle el nuevo feature de producción, es decir, sí, es fácil decir: "Ok, lo voy a desplegar en Ciudad de México" por ejemplo y que ya luego le harás el despliegue al resto de México. ¿Cómo le dices tú al servidor que solo despliegue los cambios en Ciudad de México?
Si estás en un servicio stateless. Una forma de hacerlo pudiera ser por medio de configuración dinámica del deplouement. veo que mencionas tecnologías de Aws. Te recomiendo CDK sobre Cloudformation lejos. otra es Delegarlo a un servicio propio de feature flags. Con su propio API y todo. delega la responsabilidad a el, y al consultarlo el servicio sabrá en dónde te encuentras basado en otros datos que bien se pueden mandar mediante el header, resolution de la IP, a través del enrutamiento etc...
Existen diversas tecnicas para ello. Con base a mi experiencia enlisto las que mas he usado en mi dia a dia
cree un sistema que creció mucho, el sistema lo empecé cuando no sabia nada de arquitectura, yo solo queria programar. Después descubrí todo esto y apenas estoy creando todos estos documentos, creo que nunca es tarde
Veo que existen algunos comentarios que hacen referencia a la convención que maneja Angular para commit message, esta cool y lo utilizo muy seguido, pero mi decisión para el formato de escritura depende desde el tipo de proyecto, tamaño, y cantidad de integrantes, a partir de ello tomó como referencia Conventional Commits (en esta convención de igual manera hacen referencia al formato que maneja Angular)y voy modificando el formato.
<type>[optional scope]: <description> [optional body] [optional footer(s)]
Al final lo que importa es que un commit message sea claro para las personas del equipo, ya que con un buen mensaje podemos tener una visibilidad de que paso en el commit antes de entrar analizar en el código, ya que algunos objetivos principal de los commit messages son: poder saber qué cambios vienen cuando alguien realiza un PR para un code review o si estamos buscando un error a través del tiempo de evolución del del proyecto, podemos saber a través de un mensaje claro donde se pudo haber agregado ese error.
Nunca, Nunca poner mensaje como
Hecho
No entiendo cómo funciona
Ya arregle esto
Se agregó botón
Se cambio color
Sálvame Diosito
Etc.
Revelador, la rama master no es necesariamente lo que ve el cliente
Por si desean colaborar en proyectos grandes, les comparto las reglas de Angular para contribuir:
La rama Master en Github ahora es Main
Hola!
Te comparto el enlace del curso de Git y GitHub que explica los cambios recientes que se han incorporado en algunas palabras; por ejemplo, a como bien lo explicas, ya no se dice master, sino más bien main: https://platzi.com/clases/1557-git-github/35869-cambios-en-github-de-master-a-main/
Hola, ¿Qué pasa si el nuevo feature tiene cambios importantes en la BD de datos, como se hace ese deploy granular en ese caso?
Me queda la duda del ejemplo... se supone que en la rama master decidiste llegar al feature 2 (tag version 1) y lo llevaste a prueba, pero paralelamente en la rama master se continuó con un feature 3. ¿Qué pasa con el feature 2 si en las pruebas te encuentras con un bug? ¿cómo haces la corrección del bug si la rama master tiene un nuevo feature (que entiendo sería el commit siguiente) ? Asumamos que ese nuevo feature 3 todavía está no está terminado. No entiendo como se regresa al master el feature 2 para hacerle cambios sin hacer merge del feature 3.
Hola Jenny! Esto es algo que puede ocurrir con mucha frecuencia. Por ejemplo, cuando cada feature es desarrollada en paralelo por dos equipos. Donde trabajo, lo que hacemos es tener varios ambientes y se van haciendo deploy por feature qa / staging / prod. Asi, la mayoria de los bug quedan en qa y los equipos pueden ir resolviendo antes de pasar a las demás etapas.
Vale decir que los repositorios son una cosa y la plataforma de deployment son dos cosas diferentes. Los repos están en Github y los ambientes en GCP.
Saludos!
@pabloantipan Muchas gracias por responder, me da una hebra por donde investigar. Saludos!
Hola!
Les comparto el enlace del curso de Git y GitHub que explica los cambios recientes que se han incorporado en algunas palabras; por ejemplo, ya no se dice master, sino más bien main: https://platzi.com/clases/1557-git-github/35869-cambios-en-github-de-master-a-main/
Responder
Hola Charlie! Excelente crossover que complementa esta clase! Gracias
Observando el ejemplo que diste sobre rollout, justamente los pasajes regionales tienen muchas aristas, lo primero que observó es que no se aclara dentro del pasaje que haya modificaciones del modelo de datos, muchas veces esto es algo crucial y puede romper otros despliegues. Por ejemplo, veamos un punto concreto que es la eliminacion de una tabla, lo primero que tenemos que ver en este caso si este drop que impacto tiene. Vuelvo a repetir, el ejemplo citado es un happy path.
Habia muchas expectativas por este curso en parlicular, pero hasta el momento me parece como la receta que te da algun amigo por telefono y después con los ingredientes en mano, no sabes como preparar el plato, espero mejore mas adelante. Para la gestión del Repository vale la pena leer. Que cosa es GitFlow.
Hola Sergio! Gracias por el feedback! Este es un curso muy conceptual. Mucho del como que creo estas buscando estara en otros cursos y depedera del stack que emplees
Saludos!
Si quieren entrar en detalles acerca de Git, pueden ver el curso de Git y Github: https://platzi.com/clases/git-github/
Muy interesante esta forma de usar los tags, este curso se pone cada vez mejor, hasta puede ser la base en un futuro de otros cursos de backend en platzi, haciendo implementaciones en django,laravel, java etc.
muy interesante esta clase...
Hola Kenny! Que bueno que esta clase ha despertado tu interes por aprender mas! Saludos!
