Este artículo es el primero de una serie de artículos para ingenieros de sistemas que desean desarrollar habilidades para administrar su código.
Para los administradores de inquilinos, los ingenieros de confiabilidad del servicio y los profesionales de TI, el código juega un papel más importante en el trabajo que hacemos año tras año. Ya sea que se trate de PowerShell, Terraform, JSON, XML, Markdown o incluso buenos archivos por lotes antiguos, interactuamos con el código casi todos los días.
Aquí, en Practical365.com, hay docenas de scripts que los autores han escrito y que mucha gente ha usado. Aquí hay solo un par en el último mes:
Cómo generar informes de estadísticas de reuniones para buzones de sala (infotecnologia.com)
Introducción a Microsoft Graph PowerShell SDK Parte III: Interacción con Exchange Online y SharePoint Online (infotecnologia.com)
A medida que aumenta la cantidad de código que manejamos, debemos desarrollar nuevas habilidades y adoptar herramientas que nos ayuden a administrar nuestro código fuente.
Los desarrolladores han administrado el código durante décadas. Hay una variedad de herramientas disponibles, como Microsoft Team Foundation Server, Mercurial, Subversion y docenas más. Todas estas herramientas pertenecen a la categoría de control de código fuente. El control de código fuente permite que varias personas editen la misma base de código de forma organizada y realicen un seguimiento de todos los cambios realizados. Esto es extremadamente útil, incluso si solo tiene a otra persona editando guiones.
- No tiene que usar nombres de archivo para administrar diferentes versiones. Si alguna vez ha escrito un script de más de 10 líneas, es muy probable que haya tenido un directorio con una lista de archivos como la siguiente:
- MiScript.ps1
- MyScript.ps1.bak
- MyScript.Final.ps1
- MyScript.Final.2.ps1
- MyScript.Final.ReallyFinal.ps1
- MyScript.Final.ReallyFinal.v2.ps1
Puede realizar cambios fácilmente, probar su actualización, retroceder o confirmar sus cambios.
- El control de fuente te hace pensar en lo que estás cambiando y por qué. Verá más adelante en el artículo que puede confirmar cambios con un mensaje vinculado al cambio. ¿Fue un error que solucionaste? ¿Era una característica nueva? Estas capacidades facilitan ver un historial de lo que ha cambiado con el tiempo.
- A medida que usted y sus colegas crean y mantienen más y más secuencias de comandos, el control de fuente puede permitir que su equipo administre todas sus secuencias de comandos, para saber qué versión es la más reciente y qué cambios se realizaron.
Si hoy se inicia un nuevo proyecto que requiere control de código fuente, es muy probable que use Git. Esta respuesta en el sitio de ingeniería de software de Stack Exchange tiene algunos datos y tendencias interesantes sobre qué herramientas se han utilizado a lo largo de los años.
Git fue creado en 2005 por la comunidad de desarrollo de Linux, principalmente por el propio Linus Torvalds, para administrar el código fuente del kernel de Linux. Git puede escalar desde una persona que administra algunos scripts hasta más de mil colaboradores que trabajan en el kernel de Linux.
Como se describe en https://git-scm.com, «Git es un sistema de control de versiones distribuido gratuito y de código abierto diseñado para manejar todo, desde proyectos pequeños hasta proyectos muy grandes, con velocidad y eficiencia».
Aprender Git es una inversión. Tomará tiempo. No es intuitivo cuando empiezas por primera vez. Sin embargo, vale absolutamente la pena. Si escribe código de PowerShell hoy, ¿recuerda la primera vez que abrió el shell y trató de entender cómo funcionaba la canalización? Eventualmente te sentiste cómodo con eso, pero tomó tiempo. Al igual que PowerShell, Git es un activo increíblemente poderoso que obtendrá beneficios a largo plazo para su carrera como profesional de TI.
Como mencioné anteriormente, aprender Git es una inversión. En mi opinión, cuando comience a aprender Git, debe usar la herramienta de línea de comandos de Git. Hay docenas de herramientas, GUI y entornos de desarrollo integrados (IDE) que funcionan bien con Git, y definitivamente debería comenzar a usarlos una vez que domine los conceptos básicos. Sin embargo, cuando estás aprendiendo, creo que es mejor usar la línea de comando sin formato. Esto lo ayudará a comprender lo que realmente está sucediendo e incluso cómo funcionan algunas de las herramientas debajo del capó. Si usa una herramienta que ejecuta un montón de comandos porque hizo clic en un botón, buena suerte para solucionarlo si algo sale mal. Sí, la interfaz de línea de comandos llevará más tiempo. Pero vale absolutamente la pena el tiempo extra.
Git comienza bastante simple. Puede convertir cualquier directorio de su computadora en un repositorio de Git y comenzar a rastrear los cambios en los archivos. Git agrega una carpeta oculta en ese directorio que almacena todo su historial de git y todos sus cambios. Puede usar Git en su sistema local y nunca tener que enviarlo a un repositorio como Github.com o Azure DevOps.
Una forma de pensar en Git es que divide el directorio de su sistema de archivos en tres «áreas» virtuales. Utiliza Git para agregar y eliminar archivos de estas tres áreas que se muestran a continuación (Figura 1):
Figura 1: Directorio del sistema de archivos Git
Cuando crea un nuevo archivo, va al directorio de trabajo. El comando «git add» se usa para agregar el archivo o archivos al área de preparación de git. Cuando esté listo para confirmar los cambios, se usa el comando «git commit» para enviar el archivo desde el área de ensayo al repositorio local.
Cada vez que confirma nuevos archivos o realiza cambios en los archivos, git almacena esa «versión» de todos los archivos en el repositorio. Está marcado con un hash. Siempre puedes volver a esa versión.
En primer lugar, puede descargar e instalar Git aquí. También está disponible en muchos administradores de paquetes como Chocolatey para Windows o Homebrew en Mac y Linux. Esto es todo lo que necesitas para empezar a usar Git.
Esta demostración utiliza PowerShell. Los comandos de git serán todos iguales, pero siéntete libre de usar cualquier shell con el que te sientas cómodo para crear directorios y actualizar archivos.
Cree un nuevo directorio y cambie a él. Luego, crea un nuevo archivo con algo de texto.
md gitDemo && cd gitDemo Add-Content "File1.txt" -value "one line in file1"
Tenemos un nuevo directorio con un archivo pero sin control de fuente. Convierta este directorio en un repositorio de Git inicializándolo. Tenga en cuenta el uso del punto al final del comando. Esto significa inicializar el repositorio en el directorio en el que nos encontramos actualmente.
git init .
Veamos cuál es el estado de nuestro repositorio Git. Debería mostrar un archivo que no se está rastreando, que es el archivo File1.txt que creó anteriormente.
git status
Podemos comenzar a rastrear el archivo y agregarlo al área de preparación usando el comando git add. Aquí puede usar Git add . o Git agregar nombre de archivo. Git agregar. agregará todos los archivos y actualizaciones al área de ensayo. Este es un atajo útil, pero debe recordar que puede agregar archivos individualmente. Tal vez creó un montón de archivos nuevos, pero solo desea agregar un archivo a la próxima confirmación que está realizando.
git add .
Si vuelve a ejecutar el estado de Git, verá que el nuevo archivo se agrega y está listo para confirmarse.
git status
Ahora podemos enviar el archivo al repositorio. En lugar de simplemente ejecutar la confirmación de Git, también debemos proporcionar un mensaje de confirmación. Este mensaje ayudará a identificar lo que se hizo en este compromiso. Esto puede ser muy útil uno o dos meses después cuando revise el historial de sus compromisos para ver qué cambios se realizaron.
git commit -m "This is the initial commit for this repository"
Hagamos un cambio más, agreguemos el cambio a la preparación y luego confirmemos el cambio.
Add-Content "File1.txt" -value "one more line in file1" git add . git status git commit -m "Added a second line to file1" git status
Ese último comando de estado debería mostrar que todo está limpio y que no hay nada que cometer. Hay un último comando que probaremos para que puedas ver el historial de tus confirmaciones.
git log
El comando de registro de Git enumerará el ID de confirmación, o el hash de la confirmación, el autor, la fecha y el mensaje que especificó cuando realizó la confirmación.
Una nota rápida sobre la confirmación y los mensajes de confirmación
Sugiero enfáticamente comprometer pequeñas unidades de trabajo y usar mensajes de confirmación que tengan sentido. La confirmación en sí también debe ser una pequeña unidad de trabajo que se pueda describir fácilmente en un mensaje de confirmación de una sola oración, como «Corregir error cuando el nombre de usuario es nulo» o «Actualizar secuencia de comandos para usar la autenticación moderna en lugar de la autenticación básica».
Cuando escriba un mensaje de compromiso, piense en lo que necesitaría que dijera si lo estuviera leyendo dentro de 6 meses, o si alguien más lee el mensaje. Debe ser claro y conciso.
Si no está utilizando Source Control hoy, es un gran día para comenzar. Sí, Git es un ecosistema grande y complejo. Puedes empezar poco a poco. La inversión que realice en aprender Git se convertirá en un gran activo para su carrera.
