DEV Community: Sebastian Linares L.

Profesionaliza tus proyectos personales con CircleCI + Netlify + Github Parte 2

Sebastian Linares L. — Tue, 12 Nov 2019 01:44:27 +0000

Está es la continuación de mi post post anterior. Concluiremos esta serie con la implementación del CD en CI/CD - Continuous Delivery.

Resultado 🔚

Un proyecto alojado en Netlify (free tier)
Un nuevo archivo de configuración CircleCI config.yml
Un flujo de trabajo en CircleCI que nos permitirá hacer deploy cada vez que hagamos merge a un pull request de nuestra master branch.

Continuous Delivery (CD) 🤝

En esta edición no recurriré a la documentación de Microsoft, si no que a la de continuousdelivery.com, que dice:

Continuous Delivery es la habilidad de obtener los cambios de todo tipo, incluyendo las nuevas características, cambios de configuración, bug fixes y experimentos, a producción o a las manos de los usuarios, de una manera segura, rápida y sostenible.

Una definición bastante completa. En el último post, hablamos acerca de la integración. Una instancia para un testing completo - nos gustaría -, el último checkeo para estar seguros que los cambios que hicimos a nuestra aplicación no romperán el producto final. Ahora - en el continuous delivery -, es tiempo de asegurar que nuestro usuario final reciba la aplicación de la manera más rápida e integra🏃‍♂️.

Primer paso 1️⃣: Crear una cuenta en Netlify

Entramos este link y creamos una cuenta.
Una vez que terminemos de registrarnos, seremos redirigidos a nuestro panel de control, el cual estará vacío. Hacemos click en New site from Git
Click en Github e ingresamos nuestras credenciales 🔐
Aparecerá una solicitud de instalación 🔧 que necesita hacerse en Github
Tenemos dos opciones aquí: permitir que Netlify tenga acceso a todos nuestros proyectos o solamente a los que escojamos. Elegiremos la última y solo permitiremos que Netlify vea la aplicación que creamos en el último post.
Hacemos click en Install e ingresamos nuestra clave 🔑 .
En la ventana siguiente, hacemos click nuevamente en el nombre de nuestro proyecto de Github
Ahora veremos un formulario donde podemos configurar nuestras build options para el proyecto. Lo dejaremos como está, porque así tal cual es como lo necesitamos para los siguientes pasos.
Hagamos click en Deploy Site

Si están siguiendo esta serie de posts, todo debería funcional y en un par de segundos su proyecto deberá haberse generado. Abajo del nombre de su proyecto, debería haber un link con una extensión .netlify.com. Si le hacemos click seremos redirigidos a nuestro nuevo sitio web!

Si el sitio no fue creado 🙅🏽‍♂️, sugiero estos posibles escenarios.

Su proyecto fue creado con NPM y en el 8vo paso, lo configuramos para usarse con yarn build. Solo tenemos que ir a settings > build & deploy > edit settings. Ahí podremos modificar nuestro build command para usar NPM.
Quizás a Netlify le dimos permisos para otro repositorio. Para revisar que repositorio está conectado con nuestra cuenta Netlify, vayamos a setting y abajo de la url, hacemos click donde dice Github. Ese link nos redireccionara al repositorio en conexión.

Agregar un build Hook a nuestra configuración de Netlify

En simples palabras, el build hook es un endpoint. Si enviamos un POST request vacío, desencadenaríamos el proceso de build + deploy de la rama master de nuestro repositorio.

Vayamos a settings > build & deploy y bajemos hasta build hooks.
Hacemos click en Add build Hook
Le asignamos un nombre descriptivo y guardamos.
Copíamos la url que se generó. Peguémosla en algún lugar porque la necesitaremos más tarde.

Configurar una environment variable en CircleCI

Ya tenemos una url que sirve como un endpoint para desencadenar nuestro build + deploy. Ahora vamos a usar eso en nuestro archivo de configuración de CircleCI config.yml. Pero como buenos desarrolladores que somos, me imagino que no queremos que esa url quedé pública en nuestro repositorio de Github 🤔 - cualquiera podría gatillar un deploy simplemente enviando un POST a esa url. Para esto, tenemos variables de ambiente que los amables trabajadores de CircleCi nos han provisto.

Vayamos a nuestra app de CircleCI
Hacemos click en Jobs
Hagamos click en el ícono de configuración que está al lado del nombre de nuestro proyecto
Nos encontramos dentro de la configuración específica para ese Job. Hacemos click donde dice Environment Variables
Ahora click en Add Variable
Le daremos un nombre descriptivo - awesome_endpoint -, y en el value pegamos el endpoint que guardamos anteriormente - la url del build hook de netlify
Hagamos click en Add Variable nuevamente

Casi listos, solo un paso más!

Cambiar la configuración de CircleCI

En nuestro último archivo config.yml solo ejecutamos un set de test. Ahora el objectivo es testear solo en nuestra feature branch y únicamente hacer deploy cuando hacemos merge de una pull request hacia nuestra rama master.

PRIMERO: Asegurémonos de estar en la feature branch, no en la master 🙏🏽. Si vemos el archivo config.yml, veremos la palabra jobs. Abajo de esto, solo veremos un job, build. Ahora agregaremos un segundo job, lo llamaremos deploy

En este job especificaremos en qué máquina queremos trabajar. En este caso elijamos una macos. Luego recuerdan la url que nos dieron en nuestro build hook 🧠, la usaremos nuevamente.

Su nuevo job debería verse así.

deploy:
    machine:
      macos:
        xcode: '9.0'
    steps:
      - run:
          command: curl -X POST -d {} ${awesome_endpoint}

Cómo pueden imaginar, detrás de ${awesome_endpoint} se esconde nuestra variable de ambiente con el endpoint secreto que gatilla el build + deploy del proyecto.

Ahora tenemos dos jobs, build & deploy. Como los unimos? Con workflows. Podemos agendar los jobs que queremos que se gatillen ante ciertas condiciones que previamente configuraremos. Más información aquí en la documentación.

workflows:
  version: 2
  build:
    jobs:
      - build:
          filters:
            branches:
              ignore: master
      - deploy:
          filters:
            branches:
              only: master

Primero, declaramos la palabra clave workflows. Luego, escribimos cada job que queremos ejecutar y filtramos cada uno por branches. El build job ignora la master branch, por lo tanto se ejecuta en cualquier otra rama. Por otro lado, el job deploy estipula que se ejecutará solo en la rama master. Tal como lo hablamos anteriormente, estamos pensando en hacer el testing en la feature branch y luego solo hacer deploy en master.

Nuestro archivo final config.yml debería terminar viéndose así:

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:lts
    working_directory: ~/repo

    steps:
     - checkout
     - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            - v1-dependencies-

      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      - run: yarn test

  deploy:
    machine:
      macos:
        xcode: '9.0'
    steps:
      - run:
          command: curl -X POST -d {} ${awesome_endpoint}


workflows:
  version: 2
  build:
    jobs:
      - build:
          filters:
            branches:
              ignore: master
      - deploy:
          filters:
            branches:
              only: master

Hacer commit de los cambios y push a la feature branch

El único cambio que hicimos en el código del repositorio fue en el archivo config.yml. Lo agregamos y hacemos push a nuestro remoto con git add .circleci/config.yml && git commit -m 'circleci: add deploy job and workflow' && git push origin <branch_name>

Creamos un pull request como vimos en el post anterior.

Ahora se ven los resultados de todo lo que hemos hecho en los últimos dos posts.

Primero, tenemos que esperar que los checks se completen. Específicamente el job build que es el que configuramos en nuestra master branch como protección. Si no se completa exitosamente, no podremos hacer *merge

Mientras esperamos, en CircleCI nuestro build esta corriendo

Luego de haber hecho merge del pull request, el job deploy se ejecuta en nuestra master branch

Cuando se completa, se gatilla el build hook de Netlify - el que declaramos en la variable de ambiente de CircleCI. Esto gatilla un build + deploy en nuestro sitio de Netlify - el con la .netlify.com extension.

Finalmente, luego de que la build de Netlify es exitosa, nuestro sitio web está listo!

DONE.

Últimas palabras

Esto concluye nuestro viaje. Ahora son los modestos dueños de un proyecto que hace testing y deploy automático. Siéntanse orgullosos y pueden hacerle el overkill que quieran con lo aprendido, hasta a sus proyecto más sencillos. Crean en sus proyectos, son geniales.

Saludos!

Más información

La documentación de CircleCI puede darles un mayor entendimiento de cómo usar la plataforma.

Upgrading Your Personal Project Game With CircleCi + Netlify + Github - Part 2

Sebastian Linares L. — Wed, 06 Nov 2019 02:22:20 +0000

This is the continuation of my last post on this series about upgrading your personal project game. In this edition, we'll finish implementing the CD in CI/CD - continuous delivery.

End result 🔚

A project hosted on Netlify (free tier)
A new config.yml CircleCI configuration file.
A workflow on CircleCI that will allow you to deploy on every merge of a pull request to your master branch

Continuous Delivery (CD) 🤝

In this edition I'm not resorting to Microsoft docs, but to continuousdelivery.com, which says:

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes, and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Pretty straightforward. In the last post, we talked about the integration, an instance for thorough testing - you wish -, the last revision to be sure that the changes you just made to your app won't break the end product that the user receives. Now it's all about ensuring that your user gets that new app in the quickest and seamlessly way 🏃‍♂️.

First Step 1️⃣: Create a Netlify account

Enter this link and create an account.
When you finish registering you'll be redirected to your dashboard, which will be empty. Click in "New site from Git".
Click on Github and enter your credentials 🔐.
You'll be prompted with a Netlify installation 🔧 that needs to be done on Github.
You have two options here, allow Netlify app to peak in all your projects or only on the selected ones. I'll choose the latter, only allow it on the project that we created in the last post.
Click install and write your password 🔑 .
In the next window click again in the name of your Github Project.
Now you get to a form where you can set the build options of your repository. I'll leave this as it is because it is just how I need it to be for the next steps.
Click in Deploy Site

If you are following this series everything should work and in a phew seconds your project should have built. Below your projects name, there should be a link with a .netlify.com extension. If you click it, you will be redirected to your live website!

If your site wasn't deployed 🙅🏽‍♂️ I have some guesses in what could have happened :

Your project was built with npm and in the 8th step it was set to use yarn build. You just need to go to settings > build & deploy > edit settings. There you can modify your build command to use npm.
Maybe you gave Netlify permission to another repository. To check which repository your Netlify project is linked to, go to setting and click below your app url where it says Github. That link will redirect you to the repository of this particular build.

Add a build Hook to your Netlify configuration

In simple words, the build hook is an endpoint. If you send an empty POST request to it, you unleash a build + deploy of the target branch - master in this case.

Go to settings > build & deploy and scroll down to build hooks.
Click in Add build Hook
Write a descriptive name to your build and save it.
Copy the url that was generated on save. Paste it somewhere because we'll need it later.

Configure an environment variable in CircleCI

So now we have a url that serves us as an endpoint to trigger our build + deploy. We are going to use it in our CircleCi configuration file config.yml. But as the good developers that you are, I imagine you don't want to put that same url in the public github repository config.yml file, no? 🤔 For that, we are going to use the environment variables that the people from CircleCI were kind enough to provide us.

Go to your CircleCI app.
Click in Jobs.
Click in the settings icon next to your project's name.
We entered the settings of that specific Job. Click where it says Environment Variables.
Click in Add Variable
We'll give it a descriptive name like awesome_endpoint and in the value paste that endpoint url I told you to save previously.
Click in Add Variable again.

Almost done, one step more!

Change CircleCI configuration

In our last config.yml file we only ran a set of tests. Now the goals are to test only in your feature branch and only deploy when your master branch merges a pull request.

FIRST: be sure to be in a feature branch, NOT your master 🙏🏽. If you look at the config.yml file. You'll see the word jobs. Below this, we can only see one job, build. We are going to add a second job, we'll name it deploy.

In this job we'll specify a machine to work on, in this case I chose a macos one. Then, remember the url we were given in our build hook 🧠, now it's time to use it - think it this way: Netlify calls the specified command in an environment that runs a macos virtual machine.

Your new job will look like this.

deploy:
    machine:
      macos:
        xcode: '9.0'
    steps:
      - run:
          command: curl -X POST -d {} ${awesome_endpoint}

As you imagine, behind that ${awesome_endpoint} hides the environment variable with the secret endpoint that triggers our project 👀.

Now we have two CircleCi jobs, build & deploy. How to join them? With workflows. We can schedule jobs to run in certain conditions we previously configured. More information here in the docs.

workflows:
  version: 2
  build:
    jobs:
      - build:
          filters:
            branches:
              ignore: master
      - deploy:
          filters:
            branches:
              only: master

First, we declare at top-level the workflows keyword. Then, we write each job we want to run and filter each one by branches. The build job ignores master branch, so it runs on any other branch - very useful if our feature branches will have various names. On the other hand, the deploy job clearly stipulates that it will run only in the master branch. Like we talked before, we are only thinking in a suite of tests in our feature branch before merging and only deploy our master branch.

Your final config.yml should now look like this:

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:lts
    working_directory: ~/repo

    steps:
     - checkout
     - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            - v1-dependencies-

      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      - run: yarn test

  deploy:
    machine:
      macos:
        xcode: '9.0'
    steps:
      - run:
          command: curl -X POST -d {} ${awesome_endpoint}


workflows:
  version: 2
  build:
    jobs:
      - build:
          filters:
            branches:
              ignore: master
      - deploy:
          filters:
            branches:
              only: master

Commit changes and push the feature branch

The only changes we did in this repository's code was in the config.yml file. Add it and push it to your remote repository with git add .circleci/config.yml && git commit -m 'circleci: add deploy job and workflow' && git push origin <branch_name>

Create a pull request as we saw in the last post.

Here is where everything we've done in these 2 posts shines.

First, you'll have to wait for the checks to complete. Specifically, the build job that we configured to the master branch as protection. If this doesn't complete successfully we aren't going to be able to merge.

Meanwhile you wait, on the CircleCI website the build is running.

After we merge the pull request, the deploy job runs on the master branch.

When completed, it triggers the build hook from Netlify - the one we wrote in the environment variable on the CircleCI website. This triggers a build + deploy to our Netlify site - the one with the .netlify.com extension.

Finally, after Netlify's build succeeds our site is live

DONE.

Last words

This ends our journey. You are now the proud owner of a project that tests and deploys automatically. Feel proud and you are allowed to overkill each one of your projects with these awesome features. Believe in your development game. You rock.

Best wishes.

Upgrading Your Personal Project Game With CircleCI + Netlify + Github - Part 1 [ENG]

Sebastian Linares L. — Fri, 01 Nov 2019 19:49:07 +0000

Intro

During the time I've been learning to program - because I don't know if I can say I've studied computer science as a whole-, I've done many little projects and other more ambitious - all just for learning purposes-, and as the time passes, I started building some criteria 🧠 about what's else, what spice can I add to those projects to enrich them in technologies. There is always the term "overkill" lurking around, but when it's just for learning purposes and you can set terms and goals ... just do it.

For those who haven't hopped in the CI/CD train, here I bring you a comprehensive set of steps you can take to connect your beautiful, dusty and forgotten, Todo App, that's been wandering for many months in your /projects directory.

I'll try to make this as short as possible, but it will be divided into 2 posts. This first post will be about continuous delivery and the second, I'm still not sure if it is continuous delivery or continuous deployment, BUT the technical terminology is the homework, I'm just here to show you the door, you're the one who crosses it and determines what is made of. Off we go ‼️.

End result 🔚

Basic app 👶🏽
Github repository with two branches: master and circleci
A CircleCI account
A .yml file that serves as configuration for CircleCI. It will trigger your test suite every you push content to the origin/circleci you were working on.

Continuous Integration (CI) 🤝

As Microsoft describes it, continuous integration is:

... the process of automating the build and testing of code every time a team member commits changes to version control. - microsoft docs

In simple words, for me, CI means that every time we make git push, it triggers a set of tasks, previously configured, that culminate with our app to go through multiple tests and/or builds. All this to validate the integrity of the code that you push to your remote repositories, either to Github, Gitlab, Bitbucket or other remote version control system of your preference, so at this point we are able to say: Ok, the build that originated with the changes on this last commit went through the testing suite without breaking, maybe this is ready for **production*

First Step 1️⃣

Actually, I'm not starting from the first stem, but you do it on your computers. I'm creating a new app with yarn create react-app and connecting it to a Github repository. From this point, I'll assume you've all done that.

Second step: Protect master branch in Github 2️⃣

On the main page of our Github repository, let's go settings and then branches.

Then we click in Add Rule, in Branch name pattern we write master. Then click in Require status checks to pass before merging, Require branch to be up to date before merging, finally let's click in Include administrators. The last click ensures that everyone has to respect the checks you set to the branch you are protecting, which includes administrators. If we do not check it, we will still be able to merge our feature branch with master.

As you can see, the options panel displays is a message that says Sorry, we couldn't find any status checks .... This message appears because our repository doesn't know about the possible checks that we will create in the CircleCI config file.

Let add this file immediately 🏃🏽‍♂️.

Third step: CircleCI 3️⃣

To be able to have continuous integration in our project we'll use the services that CircleCI's free tier delivers me - which by the way is more than enough for our small projects. We can find the website in this link. We register with Github and we'll have access yo all our repositories in the dashboard.

The file we are creating has a .yml extension -YAML Ain't Markup Language-, which gives us the possibility of setting the steps, for a good configuration file, in a human legible way 👇🏽.

Go to ADD PROJECTS
To the right of your project, it will say Set Up Project. Click here
Choose Node
Scroll down the page and we will see a configuration file template. Copy it
In our local repository, create and checkout to a new branch with the name of the feature you are adding to it, in this case, we will create one named circleci --> git checkout -b circleci
Create a directory named .circleci.
Inside that directory create a file named config.yml
Paste the configuration file template copied before👇🏽

Our configuration file should look like this.

jobs:
  build:
    docker:
      # specify the version you desire here
      - image: circleci/node:7.10

      # Specify service dependencies here if necessary
      # CircleCI maintains a library of pre-built images
      # documented at https://circleci.com/docs/2.0/circleci-images/
      # - image: circleci/mongo:3.4.4

    working_directory: ~/repo

    steps:
      - checkout

      # Download and cache dependencies
      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            # fallback to using the latest cache if no exact match is found
            - v1-dependencies-

      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      # run tests!
      - run: yarn test

Forth Step: Do The First Push 4️⃣

Let's stage our changes to the circleci directory with git add .circleci/
Commit the changes
We Push them to our remote with git push -u origin circleci. This will generate a new remote branch with the same name as the local one - origin/circleci
Go to our Github repository
We will find a green button that says Create pull request. If it doesn't appear, we create the pull request ourself👇🏽
Notice that the Merge pull request button is disabled. This is because we protected master with the circleci: build check. Thus, meanwhile the check is not approved, we won't be able to merge 😡.
Let's debug! The build failed and we need to check why 🤷🏽‍♂️.
In the same Github page, next to the build that fails, the one with the ❌, we see a hyperlink Details, click it. That takes us to our CircleCI account, specifically to the 'Job' that failed. There it clearly says that we need a Node version that is >=8.10. There it is! Let's fix it 👷🏽‍♂️.
Go to the config.yml file in our local repository and on line 5 change the version of your node image.

# image: circleci/node:7.10 <-- Change this
- image: circleci/node:lts # For this.

We save the file, stage our changes and push them to Github with git add. && git commit -m 'fix(ci): change to node:lts' && git push
Head to our Github repository and in the Pull request tab we can see there is a "(1)", that's our old pull request, it's still alive 👻. For it to disappear we have to explicitly close it or merge it, if not, it will be there, receiving every other commit you push to the branch we are trying to merge with, in this case origin/circleci
Now the build check passes 👏🏽
Finally, click Merge and then we can delete the branch from your Github - then we can do the same in our local repository.

And voilà we just made our first step in the looong way of continuous integration 🏆. In the next post we'll use Netlify as a hosting for this app and I'll implement Continuous Delivery with a new configuration file and some Netlify spices, so the deploy process is automatized, plus a way to make the build process faster using the cache commands that CircleCI has available for us.

👾 Here is my Twitter account, sometimes I post about web development

I hope it's useful, Chao!

Bonus: Github Flow

The way I manage my version control system is known as Github Flow, and it goes like this.

Everything in master is deployable
To work on something new, create a descriptively named branch off of master (ie: new-circleci)
Commit to that branch locally and regularly push your work to the same-named branch on the server
When you need feedback or help, or you think the branch is ready for merging, open a pull request
After someone else has reviewed and signed off on the feature, you can merge it into master
Once it is merged and pushed to master, you can and should deploy immediately

Keywords

Continuous Development
Continuous Delivery
Github Flow

Profesionaliza tus proyectos personales con CircleCi + Netlify + Github Parte 1 [ESP]

Sebastian Linares L. — Fri, 01 Nov 2019 19:49:01 +0000

Intro

Durante mi tiempo estudiando a programar - porque no sé si decir que he estudiado la "informática" como tal -, he hecho varios proyectos pequeños y otros un poco más ambiciosos - todos proyectos personales -, y a medida que ha pasado el tiempo, me he ido formando algo de criterio 🧠 acerca de qué cosa extra, que picante le puedo agregar a esos proyectos para enriquecerlos en tecnologías y a su vez enriquecer mis conocimientos. Siempre está el fantasma del overkill deambulando, pero cuando es por aprender y uno sabe sus tiempos y objetivos, solo hazlo.

Para aquellos que aún no se suben al tren del CI/CD, aquí les va una lista comprensiva de pasos a seguir para conectar su preciada, empolvada y olvidada Todo App que ha estado en el olvido en su carpeta /proyectos.

Trataré de hacer esto lo más corto posible y lo dividiré en 2 posts. El primero será acerca del desarrollo continuo y el segundo, todavía no estoy seguro si es entrega continua o despliegue continuo, pero los tecnisismos es tarea de cada uno, yo solo estoy aquí para mostrarles la puerta y ustedes tienen que ver de qué está hecha, cruzarla, etc. Vamos‼️

Resultado Final Del Post 🔚

Una app básica 👶🏽
Un repositorio en Github que funcionará con una rama master y una circleci
Una cuenta en CircleCI
Un archivo .yml de configuración CircleCI que hará un test básico cada vez que hagamos push a origin/circleci.

Integración Continua (CI) 🤝

Integración continua o Continous Integration - de ahí el CI -, según lo describe Microsoft es

... el proceso de automatizar el build y el testing del código, cada vez que un miembro del equipo hace commit a un sistema de control de versionamiento (git). - microsoft docs

En palabras sencillas - para mi -, es que cada vez que hacemos git push origin <rama_de_elección> se desencadenen una serie de procesos que culminan con que nuestra app pase por un suite de testing. Todo esto para validar la integridad del código que se "sube" a un repositorio, ya sea Github, Gitlab, Bitbucket u otro, y poder decir: "Ok, el build que se originó de mi commit reciente paso por el testing sin romperse, quizás está listo para producción.

Primer paso 1️⃣

En realidad no voy a partir del primer paso, pero ustedes lo hacen con sus proyectos personales. Yo voy a crear una app con yarn create react-app y la voy a conectar con un repositorio en github. Así que supondré que todos ya hicieron eso para continuar.

Segundo paso: Proteger la rama de github 2️⃣

Vamos a los settings de nuestro repositorio y ahí entramos en branches.

Luego hacemos click en Add rule, en donde dice Branch name pattern escribimos master. Luego elejimos Require status checks to pass before merging, después hacemos click en Require branch to be up to date before merging, y finalmente click en Include administrator porque o si no de todas maneras podrán hacer merge si son administradores, lo cual rompe completamente el sentido de hacer estos checks.

Se darán cuenta que les dice un mensaje Sorry, we coudn't find any status checks .... Este mensaje es porque todavía su repositorio no sabe que tiene disponible posibles "checks" que son los que crearemos en la configuración de CircleCI.

Lo arreglamos inmediatamente 🏃🏽‍♂️.

Tercer paso: CircleCI 3️⃣

Para poder tener integración continua en nuestro proyecto utilizaremos los servicios que nos presta el free tier de CircleCi - que es más que suficiente para nuestros pequeños proyectos personales, podemos encontrar la página en este link, nos registramos con github y tendremos acceso automático a nuestros repositorios en el dashboard de CircleCI.

El archivo que crearemos tiene la extensión .yml -YAML Ain't Markup Language-, el cual nos permite, de una manera muy legible para humanos, escribir un archivo de configuración para nuestra build de CircleCI 👇🏽.

Vamos a ADD PROJECTS
A la derecha del nombre de nuestro proyecto dirá Set Up Project. Hacemos click ahí,
Elejimos Node
Más abajo nos aparecerá un template para el archivo de configuración básica.
Copiamos esa configuración.
Creamos una carpeta, además una branch que se llame circleci y hacemos checkout a esa branch con git checkout -b circleci
Creamos un directorio con el nombre .circleci/
Adentro de esa carpeta creamos un archivo config.yml.
Pegamos lo que copiaron antes 👇🏽.

Nuestro archivo de configuración debería verse así 👇🏽.

jobs:
  build:
    docker:
      # specify the version you desire here
      - image: circleci/node:7.10

      # Specify service dependencies here if necessary
      # CircleCI maintains a library of pre-built images
      # documented at https://circleci.com/docs/2.0/circleci-images/
      # - image: circleci/mongo:3.4.4

    working_directory: ~/repo

    steps:
      - checkout

      # Download and cache dependencies
      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            # fallback to using the latest cache if no exact match is found
            - v1-dependencies-

      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      # run tests!
      - run: yarn test

Cuarto paso: Hacer el primer push 4️⃣

Agregamos los cambios al directorio circleci con git add .circleci/
Hacemos commit de esos cambios.
Hacemos push con git push -u origin circleci. Esto creará una rama remota con el mismo nombre que la rama local -origin/circleci.
Vamos a nuestro repositorio en Github.com
Vamos a encontrar una nueva pestaña que dice Create pull request. Si no nos aparece, creamos nosotros mismos el pull request 👇🏽.
Si nos fijamos, el botón Merge pull request esta deshabilitado. Esto es porque ya protegimos master con circleci:build. Por lo tanto, mientras no pase eso, no podremos realizar el merge 😡.
¡Hagamos debug! La build falló y hay que revisar por qué 🤷🏽‍♂️.
En la misma página de Github, a la derecha de la build que fallo, la que tiene la ❌, veremos un hyperlink Details, hagamos click. Esto nos lleva a nuestra cuenta de CircleCI, específicamente al Job que falló. Ahí dice claramento q espera que nuestra versión de node sea >=8.10. Aquí está el problema. Arreglemos 👷🏽‍♂️
Vamos al archivo config.yml en nuestro repositorio local y cambiamos la línea 5 de código.

# image: circleci/node:7.10 <-- Change this
- image: circleci/node:lts # For this.

Guardamos el archivo, lo agregamos, hacemos commit y push con git add. && git commit -m 'fix(ci): change to node:lts' && git push
Vayamos a nuestro repositorio Github y en la pestaña Pull request, debería ver que dice "(1)", ese es nuestro antiguo pull request, el que falló, aún está "vivo" 👻. Para que desaparezca tenemos que explicitamente hacer merge o cerrarlo, si no, estará ahí, recibiendo otros commits de algún push que hagamos en nuestro repositorio local
Ahora si la la build de CircleCI fue exitosa👇🏽
Finalmente hacemos click en Merge y luego podemos borrar el branch - podemos hacer lo mismo en nuestro repositorio local👇🏽.

Y voilá! dimos el primer paso en el laaargo camino de la integración continua 🥇. En el siguiente post utilizaremos Netlify como hosting para nuestra aplicación e implementaremos la Entrega Continua para que nuestro deploy se automatice, completando esta serie de posts 📝. Además les mostraré como hacer que nuestros jobs de circleci se hagan más rápido utilizando un cache de las dependencias, cambiando la configuración de su archivo config.yml.

👾 Aquí les dejo mi Twitter, a veces posteo sobre desarrollo web

¡Espero les sirva, saludos!

Bonus: Github Flow

La forma en la que manejo mi control de versiones es más conocida como Github Flow, que va así:

Todo en master es deployable
Para trabajar en algo nuevo crea una branch, desde master, con un nombre descriptivo - por ejemplo, nuevo-menu
Agrega todos los commit que quieras a tu nueva branch nuevo-menu y ve haciendo push esos cambios a una branch remota con el mismo nombre
Cuando creas que está lista tu nueva feature abre un pull request
Si trabajas en equipo, luego de que alguien revise tu pull request, puedes hacerle merge hacia master
Una vez que se completa el merge debería haber un deploy inmediatamente

Palabras clave

Desarrollo continuo
Entrega Continua
Github Flow