Buenas prácticas de GIT para QA

En el entorno de desarrollo de software la mayor tendencia en estos momentos es trabajar y adoptar métodos ágiles que garanticen la optimización de tiempos y calidad en el software, para lograr cubrir el ciclo de vida de desarrollo y garantizar efectividad y agilidad; lo más adecuado es que todo esté automatizado.

En este caso, para desarrollar tareas de pruebas automatizadas bajo el método de ScreenPlay, Git es una fuerte herramienta de apoyo que permite controlar versiones de nuestros scripts, nos asegura un trabajo seguro, optimizado y donde pueden participar varios colaboradores sin invadir el trabajo entre uno y otro.

 A continuación detallaremos un paso a paso de una configuración de GIT con un proyecto real.

Configuración de GIT

Primero descargar e instalar la herramienta GitBas.

1. Dirigirse a la URL del repositorio donde se encuentra alojado el proyecto, para este caso utilizamos GitLab. 

2. Seleccionamos la opción de https y copiamos la URL

3. Nos dirigimos a una ruta dentro de nuestro explorador de Windows, donde queramos guardar el proyecto. 

4. Damos clic derecho en cualquier parte del directorio y nos aparecerá una opción llamada Git Bash Here.

Esta opción abrirá una consola posicionada en la ruta del directorio.

Nota: Si queremos entrar a una ruta en específico desde la consola, digitar cd más la ruta. 

5. Digitamos git clone más la URL que copiamos en el 2do paso y damos enter.
git

La herramienta iniciará a clonar el proyecto, a algunas personas les dirá que ingresen correo y contraseña.

Nota: Si no les deja clonar por problemas de SSH, antes de mandar el comando de git clone usar git config --global http.sslVerify false.

Debe de quedar una carpeta con el proyecto clonado dentro de la ruta.

6. Entramos dentro del directorio desde el git bash usando el comando cd.

Cuando estemos dentro del proyecto nos va a decir que estamos ubicados en la ruta y en una rama llamada master.

En la anterior imagen se puede notar que quedó correctamente instalado el proyecto.

Buenas prácticas en GIT con screenplay

En este paso a paso se tuvo en cuenta un proyecto que tiene que ver con una automatización de registro.

Comando git checkout [nombre], nos permite cambiarnos entre ramas.

Comando git checkout -b [nombre], nos permite crear una rama local y ubicarnos en ella.

Ramas feature/[nombre]: Cuando trabajamos con screenplay en vez de nombre vendría el nombre como tal del feature a automatizar, para tener bien versionado el código, se puede tener varios feature en un solo repositorio, y cuando no hablamos de screenplay podemos versionar a nuestro gusto pero tenemos que crear los feature por funcionalidad automatizada.

Así creamos una rama del feature.

Y para ir a una rama:

Rama master: Esta rama sólo es modificada cuando el proyecto está en producción y en entrega, entonces cada vez que cumpla con alguna de estas 2 condiciones se podrá subir los cambios con el comando git push origin [rama].

Rama develop: Esta rama sólo es modificada cuando hay una versión estable en el proyecto, entonces cada vez que se haya hecho algo y esté estable el proyecto se puede subir los cambios con el comando git push origin [rama].

Nota: Estos feature son los mismos feature que se crean en screnplay con cucumber, en si la idea de esto es que cada vez que se tiene un feature los cambios que tiene ese feture se hacen en su correspondiente rama, si hay un feature que requiere cosas de otro solo se trae los cambios.

Aquí se puede ver como es unos cambios bien controlados.

Comando git add . : nos permite agregar todos los cambios hechos sobre el repositorio

Comando git commit -m “[comentario]” : Encapsulamos todos los agregados y le pones un comentario.

Comando git status: Vemos el estado en que está nuestro repositorio, consta de 3 tipos de estados:

1. Hay cambios pero no guardado

2. Hay cambios y se guardaron.

3. Se encapsularon ”Commit” los cambios.

4. Y está el estado en que no se ha hecho ninguna modificación.

Comando git push: Subimos lo encapsulado a nuestro repositorio remoto, puede ocurrir 2 cosas:

1. Que la rama no ha sido creada.

Nos dice que ejecutemos ese comando y lo hacemos, eso solo se debe hacer cuando se creo una rama nueva.

2. La subida de cambios por defecto:

Se pueden hacer subidas más específicas del commit que queramos subir, claro si se tiene varios commits.

NOTA: Si hay cambios no guardados y no commiteados el git push no te permitirá subir los cambios.

Comando git pull: Traemos los cambios que tiene nuestro repositorio remoto a nuestro local.