Todo el mundo tiene un entorno para realizar pruebas.
Algunas personas tienen la suerte de tener un entorno totalmente separado para Producción.
-- Anónimo
. En esta serie de artículos, me gustaría presentar y discutir varios métodos posibles para el desarrollo de software, con las tecnologías de InterSystems y GitLab. Trataré temas como: * Git 101 * Git flow (development process) * Instalación de GitLab * Flujo de trabajo de GitLab * GitLab CI/CD (Integración Continua/Entrega Continua) * CI/CD (Integración Continua/Entrega Continua) con contenedores En esta primera parte se abordará la piedra angular del desarrollo de software moderno - el sistema de control de las versiones de Git y varios flujos de Git. ### Git 101Aunque el tema principal que discutiremos es sobre el desarrollo de software, en general, y cómo GitLab puede ayudarnos en ese esfuerzo, Git utiliza conceptos de alto nivel en lugar de varios conceptos subyacentes en su diseño, los cuales son importantes para mejorar la compresión de los conceptos que veremos posteriormente.
Dicho esto, Git es un sistema de control de versiones, basado en estas ideas (existen [muchas más](https://en.wikipedia.org/wiki/Git#Characteristics), aunque estas son las más importantes): * **Desarrollo no lineal**: significa que mientras nuestro software es resultado del lanzamiento de la versión 1 a la 2 y después a la 3, sin que nos demos cuenta, el paso de la versión 1 a la 2 se realiza en paralelo, y varios desarrolladores se ocupan de un número de características/correcciones de errores simultáneamente * **Desarrollo distribuído **significa que el desarrollador es independiente de un servidor central o de otros desarrolladores, y puede establecerse en su propio entorno fácilmente * **Fusión **- las dos ideas anteriores nos llevan a una situación donde existen muchas versiones diferentes de la verdad, simultáneamente, y necesitamos unirlas de nuevo en un estado completo No estoy diciendo que Git inventó estos conceptos. No. Más bien Git hizo que fueran fáciles y populares, y junto con varias innovaciones relacionadas, por ejemplo, la infraestructura definida por código y/o la colocación en contenedores, cambiaron la manera en que se desarrolla el software. ### Principales términos de Git **Repositorio **es un proyecto que almacena datos y meta-información sobre los datos. * "físicamente" es un directorio que se encuentra en un disco * almacena archivos y directorios * también almacena un historial completo de los cambios que hubo en cada archivo El repositorio se puede almacenar: * Localmente, en nuestro propio equipo * De forma remota, en un servidor remoto Pero no existe ninguna diferencia particular entre los repositorios locales y remotos, desde el punto de vista de git.Commit es un estado fijo del repositorio. Obviamente, si cada commit almacenara el estado completo del repositorio, nuestro repositorio crecería mucho y muy rápidamente. Por lo que un commit almacena un diff , que es una diferencia entre el commit actual y su commit padre.
Diferentes commits pueden tener un número distinto de padres:
Ahora, en el caso de un padre, cada commit que sea diferente de él se llama un commit hijo. Cada commit padre puede tener un número ilimitado de commits hijos.
La **rama** es una referencia (o puntero) para un commit. Así es como se ve: ![](/sites/default/files/inline/images/risunok1_0.png) En esta imagen puede verse el repositorio con dos commits (círculos grises), el segundo es la cabeza de la rama maestra. Después de agregar más commits, nuestro repositorio comienza a verse así: ![](/sites/default/files/inline/images/risunok2.png) Este es el caso más sencillo. Un desarrollador trabaja en un cambio a la vez. Sin embargo, normalmente existen muchos desarrolladores trabajando simultáneamente en diferentes características y necesitamos un **árbol de commit** para mostrar lo que sucede en nuestro repositorio. ### Árbol de commit Empezaremos desde el mismo punto de partida. Este es el repositorio con dos commits: ![](/sites/default/files/inline/images/risunok1_1.png) Pero en este momento, dos desarrolladores están trabando al mismo tiempo y para que no se interfieran el uno con el otro, ambos trabajan en ramas separadas: ![](/sites/default/files/inline/images/risunok3.png) Después de un tiempo necesitan unir los cambios realizados y para ello crean una **solicitud de fusión** (también llamada **pull request**), que es exactamente lo que parece, es una solicitud para unir dos estados diferentes del repositorio (en nuestro caso queremos fusionar la rama de desarrollo dentro de la rama maestra) en un nuevo estado. Una vez que se revisó y aprobó correctamente, nuestro repositorio se ve de la siguiente manera: ![](/sites/default/files/inline/images/risunok4.png) Y el desarrollo continúa: ![](/sites/default/files/inline/images/risunok5.png) ### Git 101 - Resumen Conceptos principales: * **Git** es un sistema de control distribuido (no lineal) de las versiones * **Repositorio **almacena datos y meta-información sobre los datos * **Commit** es un estado fijo del repositorio * La **rama (Branch) **es una referencia hacia un commit * **Solicitud de fusión** (también llamada **pull request**) - es una solicitud para unir dos estados diferentes del repositorio en uno nuevo. Si desea leer más sobre Git, aquí puede encontrar varios [libros sobre Git](https://git-scm.com/book/en/v2). ### Flujos de Git Ahora que el lector se familiarizó con los términos y conceptos básicos de Git, hablaremos de cómo se puede administrar parte del desarrollo del ciclo de vida del software utilizando Git. Existe una serie de prácticas (llamada flujos) que describen el proceso de desarrollo utilizando Git, pero únicamente examinaremos dos de ellas: * Flujo de GitHub * Flujo de GitLab #### Flujo de GitHub El flujo de GitHub puede describirse con la frase "más fácil imposible". Aquí está: