Gestionar Aprenda a aplicar las mejores prácticas y optimizar sus operaciones.

Haga la herramienta Git de SCM la parte más fácil en una transición DevOps

Uno de los primeros cambios realizados por organizaciones que participan en una transición de DevOps es usar Git. Aquí hay cinco consejos para ayudar a simplificar la adopción de la herramienta de SCM.

La adopción de Git como la herramienta SCM de elección es uno de los primeros pasos que las organizaciones hacen cuando adoptan una transición de DevOps. A continuación, describimos cinco maneras principales en que usar Git difiere de las herramientas de administración de código fuente centralizadas y tradicionales.

Muchas organizaciones, al adoptar una estructura organizativa basada en DevOps, se están alejando de los sistemas centralizados de gestión de código fuente, como SourceSafe y Subversion, y en su lugar están adoptando herramientas de gestión de configuración de software basadas en Git, con ofertas como GitLab y GitHub como dos de las más populares. Pocas organizaciones lamentan mover su código fuente a Git, pero para aquellos que vienen de otros sistemas de control de versiones, hay una corta curva de aprendizaje. Aquí hay cinco puntos clave para recordar si está cambiando y utilizando herramientas basadas en Git por primera vez.

1. No tiene que ser distribuido

Puede descargar e instalar Git en su máquina local. Y utilizando una línea de comandos o un complemento, como EGit para el IDE de Eclipse, puede confirmar código, crear ramas y combinar código en la secuencia de desarrollo, sin tener que interactuar con ningún otro desarrollador. Git es conocido por su capacidad para facilitar el desarrollo distribuido, pero una única instancia instalada en la máquina local, con un solo desarrollador que la usa, es un caso válido para usar Git.

2. Todo está disponible localmente

Cuando se une a un proyecto que utiliza Git, clonará o bifurcará un repositorio existente. Si lo hace, no solo descarga todo el código del proyecto en su máquina local, sino que también incluye cada confirmación, revisión y rama asociados con el proyecto. La historia del proyecto reside en su máquina local, así que si desea ver cómo evolucionó el proyecto, cómo se solucionaron varios errores o cómo se mejoraron ciertas características, es solo cuestión de pasar a las ramas más antiguas y las confirmaciones anteriores. Toda la historia del proyecto está ahí sentada en su repositorio bifurcado.

3. Las ramas son sus amigas

En algunas herramientas de SCM, la ramificación del flujo maestro es un paso costoso, lo que puede causar una gran confusión con los desarrolladores. Nada podría estar más lejos de la verdad en el mundo Git. Cada vez que un desarrollador desea agregar una función, arreglar un error, jugar con su configuración de integración continua, o simplemente jugar con la base de código, se les anima a crear una rama. Si los cambios son buenos, pueden ser fácilmente desplegados en la rama maestra. Si los cambios son menos que estelares, la rama puede ser eliminada o ignorada. De cualquier manera, siempre y cuando los cambios no se combinen en el flujo maestro, no hay ningún efecto negativo en el desarrollo.

4. Clonar lo familiar, bifurcar lo desconocido

Al obtener una copia de un repositorio de Git, a veces, existe la opción de clonar; otras veces, la opción existe para bifurcar. En proyectos en los que tiene acceso de lectura y escritura, y tiene la posibilidad de guardar los cambios directamente en el repositorio que está copiando, la clonación es la opción que debe tomar. Cuando está copiando un repositorio, pero no tiene derechos de compromiso, el enfoque a tomar es bifurcarlo. Los cambios que realice se pueden hacer parte de una solicitud de extracción, en la que un usuario que tiene derechos puede examinar sus cambios y decidir si desea confirmarlos o no.

5. Obtener una distribución

Git no es más que una herramienta de SCM que permite a los equipos comprobar el código y verificar el código. Las instalaciones que proporciona para permitir la ramificación, o para permitir la fusión y el reajuste, son bastante increíbles, pero fundamentalmente, Git en sí es solo una herramienta de SCM. Sin embargo, para adoptar de verdad un mundo de DevOps –sin mencionar administrar un equipo de desarrolladores distribuidos– las organizaciones necesitan otras herramientas que se integren con su repositorio Git, como los rastreadores de bugs, la seguridad a nivel de archivos, herramientas de colaboración para equipos, e incluso ganchos hacia las herramientas de integración continua, como Jenkins o Hudson. Las distribuciones basadas en Git, como las ofrecidas por GitLab y GitHub, proporcionan este tipo de mejoras. Una distribución, junto con todas las herramientas adicionales que proporcionan, puede hacer el pasar a Git una transición mucho más fácil que si usted trabaja solo con una instalación de Git.

Cuando se trata de desarrollo distribuido, el uso de un repositorio basado en Git es una necesidad absoluta. Y no solo un repositorio basado en Git facilita el desarrollo distribuido, sino que la capacidad de crear ramas e incluso repositorios bifurcados permite a las personas ajenas al desarrollo, como la gente de operaciones que hacen compilaciones o se preparan para el despliegue, jugar con el código base sin temor a hacer daño al proyecto. Para las organizaciones que tratan de hacer de DevOps una realidad, mantener estos cinco puntos en mente simplificará en gran medida la transición a Git.

Investigue más sobre Desarrollo de aplicaciones

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

Close