Get The Latest Articles In Your Inbox.

Join the other 2000+ savvy node.js developers who get article updates. You will receive only high-quality articles about Node.js, Cloud Computing and Javascript front-end frameworks. Unsubscribe anytime.

/AWS

Como empezar a usar integración continua en tu app 🚀

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

  - Conclusión

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

Diagrama de integración continua

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 🙌

version: 2
jobs:
"testing":
docker:
- image: circleci/node:10-stretch
working_directory: ~/repo
steps:
- checkout
- restore_cache:
keys:
- app-{{ checksum "package.json" }}
# fallback to using the latest cache if no exact match is found
- app-
- run: npm install
- save_cache: # Save node_modules into cache with a checksum of the package.json
paths:
- node_modules
key: app-{{ checksum "package.json" }}
- run: npm run test # Run your tests
"deploy":
docker:
- image: circleci/node:10-stretch
working_directory: ~/repo
steps:
- checkout
- run:
name: Installing AWS CLI
working_directory: /
command: |
sudo apt-get -y -qq update
sudo apt-get install -y awscli
sudo apt-get install -y python-pip python-dev build-essential
sudo pip install awsebcli --upgrade
- run:
name: Preparing Artifact
command: |
npm install
npm run build # Here goes your build command.
cd dist # My angular app generate a Dist folder
zip ../build.zip -r * .[^.]* # Just zip your files
echo "Sucessfull building"
- run:
name: Deploying Client to S3 and Cloudfront
command: |
aws configure set preview.cloudfront true # Turn on cloudfront in AWS CLI
if [ "${CIRCLE_BRANCH}" == "production" ] # Check current branch to decide to which S3 bucket deploy
then
aws s3 sync ~/repo/dist s3://yoursite.com --delete
aws cloudfront create-invalidation --distribution-id DISTRIBUTION_ID_YOUR_SITE_PRODUCTION --paths /\*
elif [ "${CIRCLE_BRANCH}" == "staging" ]
then
aws s3 sync ~/repo/dist s3://staging.yoursite.com --delete
aws cloudfront create-invalidation --distribution-id DISTRIBUTION_ID_YOUR_SITE_STAGING --paths /\*
else
aws s3 sync ~/repo/dist s3://dev.yoursite.com --delete
aws cloudfront create-invalidation --distribution-id DISTRIBUTION_ID_YOUR_SITE_DEV --paths /\*
fi
workflows:
version: 2
build_and_deploy:
jobs:
- testing
- deploy:
requires:
- testing # Deploy require testing to be successful
filters:
branches:
only: # Only deploy for production, staging, and master branchs
- production
- staging
- master
view raw config.yml hosted with ❤ by GitHub

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

Get The Latest Articles In Your Inbox.

Join the other 2000+ savvy node.js developers who get article updates.

You will receive only high-quality articles about Node.js, Cloud Computing and Javascript front-end frameworks.

Unsubscribe anytime.

santypk4

Santiago Quinteros - @santypk4

I wish they read the docs

Read More
Latest Posts
Latest Open Source Projects
About us
Software on The Road LLC contact@softwareontheroad.com
Software on The Road
coding the future

Hire us