Use CircleCI y automatice sus deploys gratis 🚢

En una publicación futura, analizaremos cómo implementar un bucket de AWS S3 como alojamiento para su aplicación web y una distribución de AWS CloudFront como su red de distribución de contenido para entregar su aplicación web de manera escalable.

Pero primero, necesitamos una forma eficiente de administrar varios entornos.

Después de todo, si tiene un millón de usuarios, no desea arruinar su sitio utilizando un comando CLI incorrecto.

Necesitamos tener nuestra infraestructura automatizada, y esas configuraciones deben ser DENTRO de una herramienta de control de versiones como GIT o SVN.

(es broma, ¿quién usa SVN en estos días?)

Soy un gran admirador de CircleCI, lo he estado usando desde la versión 1 en 2015 cuando estaba buscando una alternativa barata a TravisCI pero también una alternativa más fácil a Jenkins.

Profundicemos en una solución de Integración Continua para su aplicación web usando CircleCI

Tabla de contenidos

• ¿Por qué implementar la integración continua? 🤔
• El archivo de configuración circleci 🙌
• Explicación 🍿
  • Traje de prueba 👮
  • Empaquetador de la aplicacion 🔮
  • Subirlo al bucket de AWS S3 📦
  • Distribución CloudFront 🕵️‍♂️

  - Conclusión

¿Por qué integración continua y entrega? 🤔

Cuando su equipo es pequeño, o cuando hay demasiadas cosas que tener en cuenta, es fácil olvidar detalles, como invalidar el caché de CloudFront después de un deploy. De lo contrario, puede terminar sin ver su actualización en el entorno en vivo.

O cuando ese tipo que hace los deploys está enfermo y no puede presionar el botón, ¿qué haces? ¿Posponer su lanzamiento a producción?

Para evitar todas estos “problemas”, aquí hay una configuración CircleCI que se implementará su código frontend a S3 e invalidará su CloudFront cache después de una fusión a la rama deseada.

Archivo de configuración CircleCI 🙌

Explicación 🍿

Aquí implementamos nuestro código en el bucket de AWS S3 en función de la rama de destino que se fusionó.

Puede volverse loco aquí y usar versionado semántico, configurar reglas de expresiones regulares para decidir cuándo una versión de etiqueta está lista para publicarse en producción o en beta.

El enfoque aquí es más clásico.

Tiene su rama master donde se fusiona todo el código, luego la rama staging es donde fusiona master cuando es lo suficientemente estable como para estar listo para la revisión manual de QA.

Luego, la rama production se fusiona con master después de que se ejecutaron todas las pruebas de aceptación y todos están contentos.

¡Ejecute sus pruebas! 👮

Por favor ejecute sus pruebas y asegúrese de que pasen antes de intentar cualquier implementación. Y recuerde emitir un error si su prueba falla, para que la implementación se detenga.

Mira mi amigo, no soy tu project manager, puedes saltarte este paso, pero piensa en tus clientes.

"testing":
  docker:
    - image: circleci/node:10-stretch
  working_directory: ~/repo
  steps:
    - checkout
    - restore_cache:
        keys:
        - app-{{ checksum "package.json" }}
        # retrocece para usar el ultimo cache si no se encuentra coincidencia.
        - app-
    - run: npm install
    # Guarda node_modules en el cache con una comprobacion del package.json.
    - save_cache:
        paths:
          - node_modules
        key: app-{{ checksum "package.json" }}
    # POR FAVOR ejecuta tus pruebas.
    - run: npm run test 

Prepara tu artefacto 🔮

La forma en que genera su artefacto depende totalmente de usted.

En mi caso, estoy implementando una aplicación Angular2.

El npm run build genera una compilación de producción en la carpeta dist, así que solamente comprimiendo eso ya estaba listo.

  - run:
    name: Preparing Artifact
    command: |
      npm install
      npm run build 
      cd dist       
      zip ../build.zip -r * .[^.]*
      echo "Artifact generated!"

La implementación en el S3 bucket 📦

Aquí estamos utilizando un enfoque simple, comprobando en qué rama estamos construyendo actualmente y decidiendo en qué S3 bucket deberíamos implementar nuestro código.

  if [ "${CIRCLE_BRANCH}" == "production" ]  # Comprueba la rama actual para decidir en que s3 bucket implementarlo.
  then
    # Remplaza tus archivos agresivamente
    aws s3 sync ~/repo/dist s3://yoursite.com --delete  

    # Invalida el Cloudfront Cache
    aws cloudfront create-invalidation --distribution-id DISTRIBUTION_ID_YOUR_SITE_PRODUCTION --paths /\* 
  elif [ "${CIRCLE_BRANCH}" == "staging" ]
  ...

El término “implementar” se usa aquí como una palabra elegante para copiar, pegar y reemplazar archivos

Invalidación de caché de CloudFront 🕵️‍♂️

   El detalle crucial ✨

  aws cloudfront create-invalidation --distribution-id DISTRIBUTION_ID_YOUR_SITE_PRODUCTION --paths /\*

Cuando actualiza sus archivos de AWS S3 bucket, a AWS CloudFront no le importará, porque su trabajo es actuar como una capa de cache.

Tienes que decirle que quieres “limpiar” el “cache”.

 Por favor, modifique esto a su gusto, tal vez desee excluir la actualización del cache de imágenes.

Conclusión 🎉

En este tutorial, aprendimos todos los pasos básicos y necesarios para crear una solución de integración continua y entrega continua para S3 y CloudFront mediante el uso de la increíble herramienta CircleCI.    Archivar la integración continua es algo en lo que vale la pena invertir tiempo. Le pagará con mucho tiempo ahorrado y prevención de errores humanos.

Recursos

• https://stackoverflow.com/questions/47344338/running-circleci-2-0-workflows-on-tags-regex
• https://stackoverflow.com/questions/48665499/circle-ci-job-on-tags-matching-regex
• https://unix.stackexchange.com/questions/182032/zip-the-contents-of-a-folder-without-including-the-folder-itself