Este tutorial forma parte de una cadena de tutoriales en las que pretendo simplemente probar tecnologías actuales. Aquí abajo podrás encontrarlos :
- Primero pasos con TypeScript con Microsoft Visual Studio Code
- Integración de GitHub / Git / GibHub Desktop y MS Visual Studio Code
- Instalación de Jest con TypeScript y MS Visual Studio Code
- Instalación de Prettier en MS Visual Studio Code
- Introducción a Parcel
- Verificación de formato de código con Eslint
También me gustaría que vieras este video de 2 minutos para entender dónde estamos y a dónde vamos
En lo que pretendo estar entretenido las próximas semanas para jugar con #TypeScript. Recomendaciones de @cesalberca Me ha dicho que, cuando haya cacharreado, en un rato lo montamos todo 😭😭 pic.twitter.com/gdfBRFMQiT
— Roberto Canales Mora (@rcanalesmora) January 8, 2020
Mi equipo es Mac
macOS Catalina
Versión 10.15.2
MacBook Pro (15-inch, 2018)
Procesador 2,9 GHz Intel Core i9 de 6 núcleos
Memoria 32 GB 2400 MHz DDR4
Gráficos Intel UHD Graphics 630 1536 MB
En este tutorial vamos a ir rápido porque partimos de todos los anteriores. Sólo me centraré en la parte de cómo conseguir que funcione GitHub Actions para crear nuestra estrategia de integración continua.
Trabajar en equipo es complicado, y más si la organización es muy grande.
Es muy posible que queramos asegurarnos que el código que tenemos en producción se compila, está verificada su sintaxis y reglas de codificación, está correctamente empaquetado, se ejecutan las pruebas automáticas satisfactoriamente y despliega automáticamente.
De ese modo, cada vez que alguien suba código al repositorio, podemos asegurarnos que cumple todos estos criterios (o nos envía un correo diciendo que alguien se lo está cargando de modo inmediato) y podemos etiquetar, crear una rama de producción y desplegar remotamente (o lo que se nos ocurra).
Incluso podríamos ir más allá. Imagina que fabricas software personalizado para otros clientes (aseguradoras) ¿cómo garantizar que las fuentes que tienes corresponden con el código en producción y que un tercero independiente establece que no se han manipulado reglas con métricas de esa calidad? Si ese tercero de confianza crea un repositorio privado de GitHub, te da credenciales para que hagas Pull Request, ya no existiría ninguna duda porque el proceso de revisión lo completa un tercero sin que puedas intervenir.
Bueno, al grano. Queremos que cada vez que subamos código TypeScript al repositorio este se compile, verifique la sintaxis, formatee y se pasen los test. Vamos a hacerlo todo con un proyecto desde cero para tenerlo para el futuro. No insisto en los comandos porque pueden cambiar. Quedaros mejor con el concepto.
Lo primero que vamos a hacer es crear un nuevo repositorio llamado rcanalescgi. Arranco GitHub Desktop y creo mi repositorio.
Lo publicamos en nuestro GitHub.
Verificamos que funciona en GitHub.
Vamos a MS Visual Studio Code. Comprobamos que en la carpeta creada en local está el fichero.gitattributes.
Creamos un directorio src y un test dentro. He creado un fichero llamado testbasico.ts. Ojo que luego me he arrepentido y los patrones por defecto asignan al nombre de los test “.test.*” así que atentos luego que lo voy a cambiar porque si no tendría que cambiar el patrón y es complicarse la vida innecesariamente.
Instalo la última versión estable de TypeScript sudo npm install -save-dev typescript
Instalamos TypeScript localmente en el proyecto npm install –save-dev typescript
Sacamos el directorio /node_modules de GIT para no subir los miles de ficheros con módulos y dependencias a GitHub.
Esto se hace creando el fichero .gitignore
Creamos el fichero tsconfig.json a través de tsc —init
Modificamos el fichero tsconfig.json para añadir el directorio de las fuentes y la salida. Ponemos el outDir y rootDir.
Instalamos ahora el sistema de pruebas Jest. Usamos el comando npm – install —save-dev jest.
Inicializamos el sistema de pruebas con jest —init para generar el fichero de configuración.
Recordar que os dije de renombre el fichero del test a suma.test.js.
Ahora con el comando jest ya lo tenemos funcionado.
Ahora instalamos Parcel. Creemos un fichero index.html e index.ts.
Usamos el comando sudo npm install -g parcel-bundler
En package.json creamos los scripts para desde npm para simplificar las invocaciones desde el entorno y luego usarlos desde Github Actions.
Con npm podemos ejecutar cada Script desde la línea de comando tipo npm start
Con npm test
Npm run-script build
Ahora instalamos eslint en el entorno local con npm install eslint —save-dev
Inicializamos el fichero .eslintrc.js simplemente diciendo las opciones con eslint —init
Ejecutamos para comprobar que funciona. Lo hace correctamente encontrando que en índex.ts hay variables que no se usan.
Ahora actualizamos los scripts para incluir las opciones de Lint.
Solo nos queda ahora instalar Prettier, el formateador. Usamos el comando npm install prettier -D
Deformamos un poco un fichero y ejecutamos con npm run format.
Así quedan los comandos. Podemos ahora ejecutar todos los comandos con facilidad y comprobar que formar cambia el fichero al formato deseado.
Veamos nuestro package.json (Creado a partir del de Cesar Alberca https://github.com/OlympiCSS/web/blob/dev/package.json). Está simplificado respecto al suyo. Os invito a visitar su proyecto sobre todo por las acciones .yml de GitHub Actions ;-).
{
"name": "rcanalesgci",
"version": "1.0.0",
"description": "Esqueleto para proyectos con CI",
"main": "./dist/index.js",
"scripts": {
"start": "parcel src/index.html",
"build": "parcel build src/index.html",
"test": "jest --coverage",
"lint": "npm run lint:js && npm run lint:css",
"lint:js": "eslint src/**/*.ts",
"lint:css": "eslint "src/**/*.ts"",
"format": "prettier --write "src/**/*.{js,jsx,ts,tsx,json,css,md}""
},
"repository": {
"type": "git",
"url": "git+https://github.com/rcanalesmora/rcanalesgci.git"
},
"author": "Roberto Canales",
"license": "ISC",
"bugs": {
"url": "https://github.com/rcanalesmora/rcanalesgci/issues"
},
"homepage": "https://github.com/rcanalesmora/rcanalesgci#readme",
"devDependencies": {
"@typescript-eslint/eslint-plugin": "^2.17.0",
"@typescript-eslint/parser": "^2.17.0",
"eslint": "^6.8.0",
"jest": "^24.9.0",
"prettier": "^1.19.1",
"typescript": "^3.7.5"
}
}
Este es el aspecto (abajo a la izquierda) que tienen todos los scripts que hemos creado.
Ahora que tenemos los scripts y la infraestructura básica, vamos a Github Actions y creamos una básica. Elegimos el WorkFlow Node.js
Nos crea un fichero básico .yml.
Cada vez que hagamos un push instalará, construirá y probará.
Cambiamos en nuestro MS Visual Studio Local (podría ser en Github directamente con el editor) cualquier fichero y hacemos commit y push a GitHub.
Comprobamos que no funciona porque nos hemos dejado alguna dependencia.
Si os fijáis, me da un error relacionado con ts-jest
Con este comando, en nuestro PC, en MS Visual Studio Code, instalamos la parte que nos falta en nuestro entorno de desarrollo
npm install –save-dev jest typescript ts-jest @types/jest
Hacemos commit y push. Y ya GitHub ejecuta correctamente sin hacer nada, recordar que está enganchado a cada push.
Os invito a que visitéis este enlace donde explica cada línea del fichero .yml y https://dev.to/bnb/an-unintentionally-comprehensive-introduction-to-github-actions-ci-blm
Bueno, con esto tenemos ya GitHub Actions instalado.
Dejo para próximos tutoriales crear una rama de producción y que, cuando etiquetemos una versión de la rama principal, se transfiera a la de producción y despliegue (ver ficheros de Cesar que ya está resuelto)
Generamos un error voluntario en el código y lo subimos (commit + push) para vez que hace GitHub.
De inmediato recibimos el mensaje de correo electrónico indicando que ha fallado la ejecución. Ya tenemos un entorno desatendido e independiente de los desarrolladores y su entorno.
Y podemos ver las consecuencias.
Bueno, a mí me ha llevado unos días entenderlo e instalar cada cosa por separado pero habéis visto que luego en este tutorial se consigue en un rato. Eso lo hace la práctica.
De todos modos nunca es conveniente ir tan en automático y hay que profundizar en el porqué de las cosas. Dejo pendientes hacer otros tutoriales sobre npm y modelos.
Aquí te dejo el enlace al siguiente tutorial:
Por cierto, acordaos de siempre añadir al .gitignore todos los ficheros importados y generados porque sino en GitHub Actions os podeis encontrar comportamientos raros. En el ciclo de CI ya se generarán.
/node_modules
/dist
/.cache
/coverage