Una guía para Git con desarrollo basado en troncos

¡Aprende la mentalidad y el proceso detrás de Trunk Based Dev!

A través de mi negocio de consultoría, equipo a las organizaciones de tecnología con las últimas y mejores herramientas de DevOps para aumentar la velocidad de sus equipos de desarrollo.

Parte de esto significa abandonar flujos de trabajo obsoletos como "GitFlow" y reemplazarlos con procesos más optimizados: desarrollo basado en troncos e implementación continua.

Pronto hablaremos más sobre "Desarrollo basado en troncales", pero es importante que esta conversación defina qué es "troncal", ya que también he visto que se usa mal.

El "tronco" es el

 main

 master

 development

He visto equipos crear una nueva sucursal y llamarla el nuevo "tronco" cada pocas semanas. Aunque aplaudo el esfuerzo, no dio en el blanco por mucho.
Veremos más sobre cómo se ve este proceso de principio a fin más adelante... Primero, permítanme dedicar un minuto a respaldar mis afirmaciones de que GitFlow está desactualizado y explicar los objetivos de pasar a un enfoque diferente.

Algunos de los mejores consejos de programación que jamás recibirá provienen de la lectura obligatoria de Eric Evan, Domain Driven Design . Domain Driven Design, para los no iniciados, es una metodología para modelar dominios comerciales en código. El consejo es el siguiente:

“Hacer explícitos los conceptos implícitos” - Eric Evans, Diseño impulsado por el dominio

¿Qué significa esto exactamente? Además, ¿cómo se aplica esto a Git o GitFlow?

Primero, definamos qué significa un “concepto implícito”. Un concepto implícito es algo que ocurre como efecto secundario de otra cosa. Por ejemplo, un efecto secundario de comprometerse con el

 development

La acción explícita realizada es comprometerse con una rama. La acción implícita causada por esa acción está ejecutando un proceso de implementación. No cambiamos explícitamente nuestro entorno de ensayo: cambiamos el código base de nuestra aplicación en una rama específica y actualizó el entorno como efecto secundario.

Luego, a menudo vemos lo mismo cometiendo contra el "tronco" (

 main/master

 master

Entonces, pregúntese: ¿cómo podemos hacer explícitos los conceptos actualmente implícitos de lanzar nuevas versiones de nuestro software?

La respuesta: haciendo que esos conceptos formen parte de nuestro modelo. La razón de la incomodidad que sentimos es que el modelo en realidad no modela nuestros entornos. Nuestros entornos en este modelo son completamente implícitos, y como puede imaginar, cosas como los entornos de producción son piezas bastante importantes, que deben modelarse explícitamente, sin duda.

Para ello, podemos crear repositorios que modelen explícitamente cada uno de nuestros entornos. Es decir, en lugar de vincular el concepto implícito de publicar e implementar código a nuestras confirmaciones, podemos definir explícitamente los requisitos de dicha publicación e implementación en una base de código.

por ejemplo, nuestro

 staging

 dependencies: - name: content repository: http://bucketrepo/bucketrepo/charts/ version: 0.0 .75 - name: mongodb-replicaset repository: https://kubernetes-charts.storage.googleapis.com/ version: 3.15 .1 - name: person-model repository: http://bucketrepo/bucketrepo/charts/ version: 0.0 .20 - name: www repository: http://bucketrepo/bucketrepo/charts/ version: 0.0 .55

¿Qué versión de cada aplicación está en preparación?

La respuesta ya no es “cualquier cosa que haya en el

 development

 0.0.75

 3.15.1

 0.0.20

 0.0.55

Mientras tanto, su entorno de producción podría estar encendido

 www

 0.0.50

 content

 0.0.74

Mucho mejor que “¿lo que hay en el baúl de cada proyecto? 🤷‍♂️”

Para lograr esto, necesitaremos abordar las cosas de una manera un poco diferente a la que probablemente esté acostumbrado.

Todavía querremos vincular algunas acciones a las confirmaciones, pero no tantos conceptos diferentes: solo queremos hacer cosas que estén relacionadas con el código base en el que estamos trabajando. En cambio, podemos limitar esa acción a lanzar un nuevo artefacto versionado del proyecto en el que estamos trabajando.

Más explícitamente, esto significa que la primera confirmación de la rama troncal lanzará la versión

 0.0.1

 0.0.2

 0.0.3

 0.0.4

Lo que son exactamente esos artefactos versionados variará según el tipo de proyecto en el que esté trabajando, pero generalmente son imágenes de Docker, repositorios de gráficos o varios paquetes específicos de lenguaje como NPM o lanzamientos de Maven.

A continuación, podemos conectarnos al proceso de lanzamiento y con cada nuevo lanzamiento, causado por cada confirmación verificada en Trunk, para actualizar explícitamente el entorno de ensayo .

Luego, una vez que se verifique la combinación explícita de artefactos versionados en el entorno de prueba en ejecución, todos se pueden mover a producción enuna sola confirmación explícita .

Así que, en pocas palabras, eso es un desarrollo basado en troncales bastante moderno.

No está tan mal, ¿verdad?

Puede usar una herramienta como Jenkins X para configurarlo de inmediato. Usar JX puede ser un poco abrumador, ya que se basa en Kubernetes y en varias herramientas del ecosistema de Kubernetes. En mi curso, DevOps Bliss , analizo la configuración de un sistema como este de principio a fin, además de otros temas como SSO, pruebas de carga y más. ¡Échale un vistazo si estás interesado!

¿Qué hay exactamente en

 git

¿historia?

Con nuestro flujo de trabajo de desarrollo basado en troncales definido, vale la pena tomarse un momento para explicar cómo pensar en lo que su proyecto

 git

El historial de tu repositorio es una serie de confirmaciones en una lista ordenada. Para moverse a diferentes puntos en ese historial, se utilizan punteros. Estos punteros se llaman

 branches

 tags

Echa un vistazo a esta imagen extraída de la documentación de Git - Branches in a Nutshell .

Es útil recordar esto mientras trabaja con Git.

Toda esta estructura, las confirmaciones, los punteros, etc., se copian en su máquina cuando clona un repositorio. Sin embargo, no se actualizan automáticamente.

Probablemente estés acostumbrado a usar

 git pull

 origin

En cambio, quiero mostrarle algunos comandos alternativos para ayudarlo con su flujo de trabajo de desarrollo basado en troncales.

Flujo de trabajo general

En la siguiente sección, quiero capturar la toma de decisiones del "día en la vida" y los flujos de trabajo de git que deberá emplear cuando trabaje en un proyecto que sigue el desarrollo basado en troncos.

En primer lugar, ya sea que esté trabajando directamente en la rama troncal (sí, esto está bien), o en una rama que se fusionará con la rama troncal, necesitará saber qué está sucediendo en Github, información como, tener otros desarrolladores cambiaron el código desde la última vez que revisé?

Supongo que está familiarizado con el flujo de trabajo básico de git de

 add

 commit

 push

 pull

 pull

Para hacer eso, vamos a empezar con un

 git fetch

 git fetch

A medida que trabaja en su próxima solución o función, ya sea directamente en la rama troncal o en una rama de corta duración que eventualmente se fusionará con la rama troncal, también lo hacen otros desarrolladores.

Están empujando y tirando de la misma

 remote

 origin

El comando

 git fetch

 git

Entonces, mientras esté ocupado trabajando, de vez en cuando, ejecute:

 git fetch --all -p

los

 --all

flag le dice a git que obtenga de cualquier

 remote

has añadido,

 origin

o de otro modo. los

 -p

la bandera representa

 prune

lo que le dice a git que puede limpiar los punteros de rama eliminados, etc.

Entonces sabrá si hay alguna actualización que necesite traer a su copia local.

Aquí hay un ejemplo de cómo se ve:

 > git fetch --all -p Fetching origin From github.com:servicebus/kafkabus - [deleted] (none) -> origin/renovate/mocha-7.x remote: Enumerating objects: 150, done . remote: Counting objects: 100% (150/150), done . remote: Compressing objects: 100% (58/58), done . remote: Total 198 (delta 125), reused 97 (delta 92), pack-reused 48 Receiving objects: 100% (198/198), 362.90 KiB | 1.31 MiB/s, done . Resolving deltas: 100% (144/144), completed with 6 local objects. 98169c3..6b4ca35 master -> origin/master * [new branch] renovate/commitizen-4.x -> origin/renovate/commitizen-4.x * [new branch] renovate/kafkajs-1.x -> origin/renovate/kafkajs-1.x * [new tag] v2.0.1 -> v2.0.1 * [new tag] v2.0.2 -> v2.0.2 * [new tag] v2.0.3 -> v2.0.3 * [new tag] v2.0.4 -> v2.0.4

En respuesta a la

 git fetch

 master

 origin

 98169c3..6b4ca35

 git log

 98169c3

 > git log commit 98169c3fabf3052dd89fe0c6900bc3c11a0252a4 (HEAD -> master, tag: v2.0.3) Author: Patrick Lee Scott <[email protected]> Date: Sat May 23 13:48:00 2020 -0400 fix: high throughput test already uses no transactions # ... more commits ...

Entre paréntesis podemos ver algunos indicadores para este compromiso:

 HEAD

 master

 tag: v2.0.3

Con esa información en mente, querremos

 rebase

 origin/master

 6b4ca35

 98169c3..6b4ca35

Dependiendo de nuestra situación, querremos usar una reorganización regular o interactiva.

Trabajando en una solución directamente contra la rama Trunk

Si está trabajando en una solución que se puede hacer fácilmente, no hay problema, en mi opinión, con comprometerse directamente con la rama troncal. He trabajado en equipos con 20 ingenieros haciendo esto, y les prometo que está bien, siempre y cuando tenga un proceso de CI/CD sólido. Si este proceso falla, lo peor que pasa es nada. La compilación se marca como fallida, no se publica ni promociona nada.
La única regla es que si rompes la construcción, ahora es tu trabajo arreglarlo, ¡y esa es la máxima prioridad!

Si tiene miedo de esto, está bien usar una rama, y cubriré ese flujo de trabajo a continuación.

Entonces, cuando está trabajando directamente en el tronco, ha obtenido información de Github y hay nuevas confirmaciones para incorporar, ahora es el momento de

 rebase

 git rebase

A

 rebase

 origin/master

 git rebase origin/master

Esto solo funciona DESPUÉS de una búsqueda; de lo contrario, git no conoce la información sobre nuevas confirmaciones y ramas del

 remote

 origin

 fetch

 rebase

Todas las confirmaciones que haya realizado después de la confirmación inicial, que es

 98169c3

 origin/master

 origin

 6b4ca35

 > git rebase origin/master First, rewinding head to replay your work on top of it... Fast-forwarded master to origin/master.

Ahora, cuando corro

 git log

 fetch

 98169c3..6b4ca35

 > git log # ... your commits ... commit 6b4ca353091a7d6a9eeba8ee5b1978112a81cabf (HEAD -> master, origin/master, origin/HEAD) Author: Renovate Bot <[email protected]> Date: Wed Nov 4 06:34:00 2020 +0000 chore(deps): update dependency jest to v26.6.3

Si no hay conflictos, este será un comando bastante simple.

Si hay conflictos, deben resolverse primero. Para resolver conflictos, en su IDE, solucione los conflictos y, cuando esté listo, guarde los cambios, agréguelos al área de preparación de git y luego ejecute

 git rebase --continue

Para aprender más sobre

 rebase

Para obtener más información sobre cómo resolver conflictos, recomiendo aprender la herramienta VSCode Merge: Control de versiones en Visual Studio Code .

Trabajando en una sucursal que se fusionará con Trunk a través de una solicitud de extracción

Si está haciendo algo más que una solución rápida, como trabajar en una nueva función, es probable que desee trabajar en una rama.

 git rebase -i origin/master

Lo anterior

 git rebase

 master

 master

Esto mantiene limpio el historial de la rama maestra y la reversión es fácil de realizar.

La gente debatirá sobre los méritos de hacer esto versus no hacerlo, pero dejemos de lado todas esas razones por ahora, y concentrémonos en cómo hacerlo.

Si especifica el

 -i

 --interactive

Esto te permite

 reword

 squash

Hacerlo te lleva a un editor en tu Terminal llamado

 vim

 :wq

Aquí hay un ejemplo de la documentación de git ( Git - Historial de reescritura ):

 pick f7f3f6d Change my name a bit pick 310154e Update README formatting and add blame pick a5f4a0d Add cat-file # Rebase 710f0f8..a5f4a0d onto 710f0f8 # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message. # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out

Para aplastar todas las confirmaciones, use VIM para editar los mensajes que dicen

 pick

 s

 squash

 pick f7f3f6d Change my name a bit squash 310154e Update README formatting and add blame s a5f4a0d Add cat-file

Esto dará como resultado una sola confirmación,

 Change my name a bit

Digamos que también desea cambiar el mensaje de confirmación, en su lugar, puede editar las confirmaciones de esta manera:

 r f7f3f6d Change my name a bit s 310154e Update README formatting and add blame s a5f4a0d Add cat-file

Si guarda este cambio, aparecerá otra ventana de VIM que le permitirá escribir un nuevo mensaje de confirmación para el

 r

 reword

 git push origin/<branch> --force

Después de

 rebase

 origin

Debe decirle a git que tiene la intención de cambiar el historial usando el

 --force

ADVERTENCIA: ¡No debes forzar a empujar al maestro, solo a las ramas!

Rebasando cuando tienes cambios sin guardar

¿Necesita reorganizar pero tiene cambios no confirmados?

Si intenta hacer esto, recibirá un error que le indicará que debe confirmar o guardar sus cambios para volver a establecer la base.

 > git rebase origin/master error: cannot rebase: You have unstaged changes. error: Please commit or stash them.

Si está listo para cometerlos, adelante y hágalo. De lo contrario, puede guardarlos, realizar la reorganización y luego recuperar los cambios del alijo nuevamente.

 git stash

Para poner todos sus cambios a un lado en un espacio temporal, ejecute:

 git stash

Luego, puede completar la reorganización:

 git fetch --all -p git rebase origin/master

Una vez que se completa la reorganización, puede recuperar todos los cambios en los que estaba trabajando desde su alijo:

 git stash pop

 --autostash

El flujo de trabajo anterior es lo suficientemente común como para que rebase realmente admita una bandera,

 --autostash

 git rebase origin/master --autostash

Conclusión

Aunque pueden ser más pasos que

 git pull

 fetch

 stash

 rebase

¡Espero que comprenda los beneficios de hacer explícitas nuestras operaciones previamente implícitas y cómo puede usar algunos comandos nuevos de git para facilitar ese proceso!

Si desea implementar la implementación continua en su organización y necesita ayuda, comuníquese conmigo a través de mi sitio web patscott.io . Si eres un ingeniero del tipo DIY como yo, ¡mira mi curso DevOps Bliss en su lugar!

Publicado anteriormente en https://www.cloudnativeentrepreneur.com/blog/a-guide-to-git-with-trunk-based-development