Integración Continua en GitHub con AppVeyor (parte 2)

En esta segunda parte, Jorge nos amplía y completa un poco más la anterior entrada sobre la Integración Continua con AppVeyor, para mostrarnos cómo generar y publicar una release automáticamente.


 

Generación del artefacto

Lo primero que será necesario es configurar un “artifact”, que sera lo que se haga “push” hacia GitHub, para ello, en la pestaña “SETTINGS” en el menú “Build”, haremos que los resultados que nos interesen se añadan a un .zip, creando un “After build script”, en el cual meteremos los binarios que nos interese. Previamente a eso, vamos a indicarle en la parte superior, que queremos que la compilación utilice “debug” y “release”.

El script:

7z a PostAppVeyor_%configuration%.zip %APPVEYOR_BUILD_FOLDER%\%APPVEYOR_PROJECT_NAME%\bin\%configuration%\*.exe

Añadirá todos los .exe que haya en la carpeta al fichero que indicamos, en caso de necesitar añadir otros ficheros o librerías, se podría indicar cambiando el patrón de búsqueda o poniendo rutas absolutas.

Con esto, AppVeyor va a generar el .zip, ahora sólo queda hacer que sea público como resultado de la compilación. Para eso, en la pestaña “SETTINGS”, en el menú “Artifacts”, lo creamos mediante el botón “Add artifact”.

Seleccionando el .zip que se ha generado mediante el script, se le pone un nombre con el cual publicarlo en AppVeyor (hay que tener en cuenta que AppVeyor borra todos estos archivos a los 6 meses).

 

Publicación del artefacto

Después de todo lo anterior, sólo nos queda publicar los binarios en el apartado de “Release” de GitHub cuando nos interese. Para ello, lo primero de todo, necesitamos generar un token en GitHub para AppVeyor. Esto se hace desde el perfil , en el apartado “Settings/Developer Settings/Personal Access Tokens” pulsando en “Generate new token”.

Tras darle un nombre, los permisos que necesitamos asignarles son simplemente “public_repo” y pulsar en “Generate token”.

Esto nos genera un código alfanumérico, que debemos copiar, ya que lo necesitaremos en AppVeyor para configurarlo.

Una vez tenemos el token, nos vamos a AppVeyor y en la pestaña “SETTINGS” en el menú “Deployment”, seleccionamos “Add deployment”.

En el desplegable, hay que seleccionar “GitHub Releases”. Cabe destacar que vamos a configurarlo para que sólo se publiquen como release los “Tags” del repositorio en la rama master. Para eso, vamos a configurar los parámetros de publicación que se ofrecen, teniendo especial cuidado en añadir una condición que sera “APPVEYOR_REPO_TAG” = true, para que sólo las etiquetas se suban a GitHub Release. Un ejemplo de como configurarlo seria el siguiente:

Una vez todo listo, solo nos queda crear un tag en nuestro proyecto, y pushear el tag a Github, esto iniciará el proceso, y cuando acabe, se podrá ver el resultado en el apartado “releases” del repositorio de GitHub.

 

Con esto queda cerrado el ciclo de despligue que junto a la entrada anterior sobre integración y testeo continuo, nos permite llevar nuestro código a cotas de calidad de desarrollo muy altas, preparando a su vez el proyecto sofware para poder gestionarlo cómodamente y de manera segura ante eventuales contribuyentes.

 

Integración Continua en GitHub con AppVeyor (parte 1)

En esta ocasión tengo el gusto de presentar a Jorge, un excelente compañero de trabajo y un grandísimo profesional. En su día a día siempre anda buscando la mejor forma de hacer las cosas y en esta ocasión nos trae un detallado tutorial de Integración Continua, ámbito en el que recientemente se ha sumergido, y del que hoy nos presenta unas pildoritas de sabiduría y buen hacer.


GitHub, con todo el revuelo que ha provocado la compra por parte de Microsoft, es uno de los mayores repositorios de código que existen, y el mayor de código libre. Dispone de múltiples herramientas que ayudan al desarrollo de aplicaciones y testeo de aplicaciones que en muchos casos no son explotadas, lo cual es una lástima ya que son gratuitas (siempre que tu repositorio sea público) y aportan una gran ayuda.

En esta entrada vamos a hablar sobre una de esas herramientas llamada AppVeyor, ¿y que es AppVeyor? Es una herramienta de integración continua que permite realizar compilaciones, ejecutar teses, y publicar binarios, todo ello con unos pocos clicks gracias a su alta integración en GitHub (y encima gratuito si tu repositorio es público).

Llegados a este punto, se puede pensar, ¿qué me puede aportar a mi todo eso? La respuesta es sencilla, si tienes algún repositorio en el que colaboras con más gente, siempre sabréis que los cambios van a compilar, y en el caso de que tengáis test unitarios, que los ha pasado, y además de todo eso, publicar las “release” si así lo queréis. Vale, ahora pensarás, yo soy un desarrollador independiente, que no comparte repositorios, y tampoco me preocupo en sacar ninguna “release”, ¿en qué puede ayudarme a mi? Fácil, puedes configurar diferentes “build” para diferentes entornos, y probar que tu código es perfectamente funcional en varias plataformas y versiones sin necesitar disponer de esas máquinas para compilar en ellas.

 

Compilación

¿Te he convencido? Pues vamos a ver como podemos configurar esta herramienta para nuestro repositorio. Lo primero es registrarnos en su web (algo muy fácil usando nuestra cuenta de GitHub).

Con sólo eso, ya estamos registrados, y llegamos a nuestro “dashboard”, que por el momento estará vacío, pero vamos a solucionarlo pulsando en “NEW PROJECT” .

Para este ejemplo, he creado un repositorio en mi perfil llamado PostAppVeyor, el cual aparece automáticamente, y simplemente hay que pulsar en “ADD”.

Ya tenemos nuestra integración lista, aunque de momento no haya hecho nada, veamos qué pasa si pulsamos en “NEW BUILD”.

Pulsando esto, se lanzará una compilación que se puede seguir desde “LATEST BUILD”.

Un detalle importante, es que al haber añadido AppVeyor al repositorio, se establecen automáticamente los WebHooks para notificar a GitHub los resultados, y si miramos el historial de commits del repositorio, se puede ver el resultado.

Esto también se aplica automáticamente para los “Pull Request”, de modo que siempre se comprobarán las modificaciones que haya sobre el repositorio.

 

Test unitarios

Vale, el repositorio compila, ¿cómo añado los teses? Otra respuesta fácil, AppVeyor es capaz de detectarlos automáticamente. Añadamos un test al proyecto y veamos que pasa al “pushearlo” a GitHub. Automáticamente se inicia una compilación pero… ha fallado, ¿por qué?, si en Visual Studio pasaba el test sin problemas…

Vale, esto es debido a que los teses unitarios de Visual Studio, necesitan descargar paquetes NuGet. Vamos a solucionar esto yendo a la pestaña “SETTINGS” y al menu “Build”. Hay que buscar “Before build script” para añadir un evento previo a la compilación, que haga un “nuget restore”, tras esto, basta con pulsar en “Save” y ya estaría listo.

Ahora que tenemos todo lo necesario, vamos a volver a probar (Mediante el botón “RE-BUILD” del resultado que ha fallado) y ¡sopresa!, ya funciona correctamente.

Pero espera… a mi no me dice eso. Mis teses no se ejecutan, ¿qué pasa? Bueno, es posible que tu proyecto este hecho en un Visual Studio superior al que usa por defecto (2015), y el descubrimiento de teses unitarios no haya funcionado del todo bien, esto podemos solucionarlo rápidamente seleccionando la versión de Visual Studio que vamos a utilizar (en mi caso 2017). Volviendo a la pestaña “SETTINGS”, pero esta vez en el menú “Environment”, seleccionando Visual Studio 2017 y damos a “Save”.

Veamos el resultado ahora pulsando en “RE-BUILD”…. ¡¡¡Premio, nuestros teses ya se ejecutan!!!

Con todo lo que hemos hecho hasta ahora, tenemos un repositorio que comprueba automáticamente si el código compila correctamente, y ademas ejecuta los teses unitarios para comprobar que sigue cumpliendo con el funcionamiento esperado.

En la próxima entrada veremos cómo generar y publicar las “releases” a partir de nuestro código compilado y testeado.

 

Ocultar partición OEM tras actualización “Windows 10 April 2018 Update”

Windows 10 April 2018 Update” (Actualización de características a Windows 10, versión 1803) es una actualización que ya lleva tiempo liberada, pero que hasta hace poco no me había atrevido a instalar por ciertos problemas que ocasionaba a los sistemas tras su instalación. La mayor parte de los problemas han sido solventados y actualmente el mayor problema que arrastra esta actualización es el de hacer visible desde el explorador de archivos la partición OEM (Original Equipment Manufacturer) que viene en tu equipo y que contiene:

  • Información de tu equipo
  • Herramientas para restaurar el sistema al estado de fábrica.

Dicha partición que ahora puedes ver y que te avisará constantemente de que hay falta de espacio siempre estuvo ahí, lo que pasa es que siempre estuvo oculta. Microsfot por alguna razón, introdujo este problema que a día de hoy sigue sin resolver de manera oficial con alguna actualización.

Si vas al “administrador de discos” de Windows verás dicha partición, pero no podrás hacer nada con ella para ocultarla.

La solución para ocultar la partición y evitar que el sistema nos avise constantemente de la falta de espacio en dicha partición, evitando también tener acceso desde el explorador de archivos a una partición a la cual NO deberíamos tener acceso directo, pasa por abrir la consola de comandos con privilegios de administrador y ejecutar los siguiente comandos:

diskpart
DISKPART> list volume

  Núm Volumen Ltr  Etiqueta     Fs     Tipo        Tamaño   Estado     Info
  ----------- ---  -----------  -----  ----------  -------  ---------  --------
  Volumen 0     E                      DVD-ROM         0 B  Sin medio
  Volumen 1     D   DATA        NTFS   Partición    931 GB  Correcto
  Volumen 2     C   OS          NTFS   Partición    237 GB  Correcto   Arranque
  Volumen 3     F               NTFS   Partición    499 MB  Correcto
  Volumen 4         SYSTEM      FAT32  Partición    260 MB  Correcto   Sistema

La herramienta “dispart” nos permite gestionar los volúmenes de nuestro sistema, escribimos “dispart” para activar la herramienta. Con el comando “list volume” listaremos todos los volúmenes disponibles en nuestro sistema. La partición OEM del fabricante suele rondar los 500 MB. Podremos identificarla fácilmente gracias a la letra con la que aparece en el explorador de ficheros. En mi caso tiene la letra F y es el volumen 3.

Ahora procedemos a ocultar la partición eliminando la letra de la partición y manteniendo la misma con los siguiente comandos:

DISKPART> select volume 3

El volumen 3 es el volumen seleccionado.

DISKPART> remove letter=F

DiskPart quitó correctamente la letra de unidad o el punto de montaje.

Ahora si vamos al explorador de archivos, veremos que ya no nos aparece la partición y por supuesto ya no nos lanza continuamente el mensaje de falta de espacio en la misma . Si vamos al administrador de discos o ejecutamos de nuevo el comando “list volume” de diskpart, veremos que la partición ya no tiene letra asignada pero sigue ahí.

Ya tenemos la partición de nuevo como siempre estuvo , oculta! 😉

 

Hidden Console Start (HCS) – Esconde la consola y lanza procesos/aplicaciones en segundo plano

Dicen que no te das cuenta de algo hasta que lo pierdes… Esto es lo que me ha pasado cuando recientemente mi orientación profesional ha cambiado y he tenido  que trabajar con sistemas Windows en vez de GNU-Linux.

Acostumbrado a tener corriendo servicios en distintas máquinas con GNU-Linux acabas echando de menos su shell y la bestialidad de herramientas que hay. Vale sí lo reconozco, al final trabajaba en una máquina Windows, pero porque sigo pensando que las herramientas de desarrollo siguen siendo mejor que las que hay disponibles en GNU-Linux. Hay que reconocer que un Windows lo uso sólo para desarrollar (eso sí multiplataforma) y para jugar, para lo demás GNU-Linux sin duda!!!

Una de las cosas que he echado en falta recientemente es la posibilidad de usar el operador & de background tan potente en GNU-Linux. Este operador permite lanzar un proceso que se sigue ejecutando sin bloquear la shell y si la cerramos, éste sigue en segundo plano. Pues esto tan chulo, no puedes hacerlo en un Windows, porque su comando start no lo permite y la opción /B del comando no impide que al cerrarse la consola de comandos el proceso que has lanzado muera. A no ser que el proceso que has lazando cree su propio hilo no dependiente del proceso de la consola. Y tampoco es posible lanzar un proceso de consola de comandos sin consola, a no ser que esté programado explícitamente que la consola se oculte o no aparezca. Windows en este aspecto se cubre mucho, porque la única forma de crear procesos en background es construyendo servicios de Windows que tienen sus propias reglas a cumplir y por consiguiente hace falta desarrollo específico para que algo corra en segundo plano.

Visto el panorama y teniendo cierto conocimiento e idea, me decidí a generar una herramienta similar que funcionase en Windows como el operador &, o por lo menos a intentarlo. Para ello lo primero pensé en que quizás lo más adecuado fuese hacerlo en multiplataforma y generar una solución que funcionase tanto en Windows como en GNU-Linux. Atendiendo a este requisito, enseguida a mi mente llegó Python, porque además su instalación de paquetes es sencilla y potente a partes iguales, por no decir que es posible generar binarios (por ejemplo un .exe en Windows) si hiciera falta gracias a herramientas como py2exe y PyInstaller.

Con el punto de partida claro y unas horas de desarrollo, consigo lo que bautizo como Hidden Console Start o HCS. El proyecto puedes encontrarlo en Github:

Y su instalación es sencilla si tienes ya Python en tu equipo. En caso de no tener Python, pásate por la web de Python y descárgate la última versión disponible. Una vez instalado Python, solo tienes que ejecutar el siguiente comando en el CMD o PowerShell para instalar HCS:

pip install hcs --upgrade

Una vez instalado puedes ejecutar el proceso o aplicación que se quiera ejecutando HCS de la siguiente forma:

hcs -e "P1" "P2" ... "Pn-1" "Pn"

Pongamos un ejemplo:

hcs -e "ping 127.0.0.1 > log1.txt" "ping 192.168.1.17 > log2.txt"

En el ejemplo se lanzan dos comandos ping a distintas direcciones que son guardados en log1.txt y log2.txt respectivamente. Como se puede ver la consola de comandos no queda bloqueada y la información de los comandos ejecutados se va guardando el los ficheros.

Si por alguna razón tus procesos o aplicaciones no mueren o acaban, puedes finalizarlos en el caso de Windows abriendo el administrador de tareas:

Y en el caso de GNU-Linux con htop:

De esta forma podemos lanzar procesos y aplicaciones en segundo plano en sistemas Windows de una forma más o menos equivalente a como lo haríamos en GNU-Linux. Y obviamente podríamos usar HCS en GNU-Linux porque también funciona, pudiendo usarlo de la misma manera que en Windows.