Luis
Luis Web Developer. Cycling passionate.

An opinionated implementation of JAMstack, Netlify, and CI/CD pipeline

In this article we would provide an overview of our approach to JAMstack, our ideal CI/CD pipeline implementation, let’s jump right in! The Tignum Engineering Team

Back in time at Tignum

The first approach to CI/CD at Tignum was using Jenkins. The team experience with Jenkins was high, and we were confident that this was the right tool for the job.

How was this implementation working for the team? At that moment https://tignum.com was a static website. Because the structure and the requirements were simple, Jenkins was enough to cover all CI/CD needs.

The first problems with Jenkins began to appear when the project grew, more people were involved, and more pull requests were opened daily. Some factors we found problematic with Jenkins:

  1. Overhead of deploying Jenkins in combination with container orchestration system
  2. Bottleneck, depending on another team to do the deployments, not full ownership.
  3. Complex maintenance, updating Jenkins, and relying on 3rd party plugins
  4. Most modern CI/CD platforms today have adopted YAML for pipeline configuration. Jenkins has not.
  5. Jenkins has a lot of redundant plugins. Knowing which one to use takes some experimentation and failed attempts.

The time invested in finding of why a deployment was not successful, was far from ideal. Solving deployment issues was taking us some time. Involving other colleagues for support in case those issues appeared, was quite common.

So, it became clear that we needed a different approach to CI/CD. The goals of the team were:

  1. Automate testing and releases
  2. Remove as much as possible the humans in the process
  3. More tests will result in fewer bugs, and reduce fear of change
  4. Increase innovation by reducing fear of change
  5. Gain automation allows more time for improving the existing product.
  6. Speed up iterations.

Our current Web Stack and Products

Tignum nowadays has two main web products that are using the new CI/CD implementation:

The tools that are part of this new approach following JAMstack are: Gatsby, Strapi for the static website tignum.com and Nuxt for the Web Application My X. So let’s dive a little more into how are built.

How the stack looks like at Tignum

JAMstack at Tignum

One characteristic of JAMstack is the developer experience. After several years of working with the old approach that includes several layers on the client and server-side. JAMstack is way more simple, and the focus shifts to performance. One simple example, Time To First Byte can be optimized with much fewer iterations and factors to take into account compared to the previous approach.

One image will help to make it clear:

JAMstack

Why Netlify?

Note: We are not going to recommend direct static website hosting with, for example, S3 and Cloudfront, or Firebase, or any other similar services. We consider those to be old ways of deploying static web pages nowadays. We decided between services that are purpose-built for static site hosting, and that they offer tooling on parallel to increase the productivity, not just asset buckets.

Last step on CI/CD process is deployment, main reason for Netlify? Simplicity, the full configuration does not take more than half an hour. Connect a repository and point the domain to the web application.

When environments are ready, deployments become something as fast as one click. With one click, you have access to a preview, the moment you merge a PR to the branch that will go to production.

Need to check for the result of the deployment? Just open the deployed preview, check, and if not right, click to redeploy the previous version.

To get to the same results with Jenkins involved way more steps, for example:

  1. Creation of the environments in our infrastructure, develop, production
  2. Connect Jenkins to those environments
  3. Set the task for all the different stages of the development and deployments
  4. When versions are ready for production, create fixed versions
  5. When fix versions ready, Jenkins job takes those fix versions and deploy them to production

As a final thought, there are no bad tools, just the right tool for the job. Very often the problems come through complex implementations.

So, Keep It Simple, Sailor!

Thanks to everyone that contribute to make this implementation possible, and for their ideas for this post:

Follow us on:

References