CI/CD series - GitLab: everyone deserves to deploy at high velocity

Lenny writes…

Iteration in a direction leads to an optimal solution. Iteration without direction leads to spaghetti code and Frankenstein UX. Simply because you are making changes faster doesn’t mean they are the right changes. The feedback loop is critical.

This is a big reason why GitLab focuses so much on delivering an entire DevOps platform in a single application. When Agile planning, Source Code Management, CI/CD and Monitoring are in a single application, you can have a single conversation thread throughout the entire Software Development LifeCycle (SDLC) and all teams from PMO and Dev to Security and Ops can have visibility into the feedback loop.

CI/CD enables smaller batch sizes.

Smaller changes mean code is easier to review, easier to test and easier to roll back when there’s a problem. This can result is fewer bugs and reduced defects in production. But, if you aren’t reviewing, aren’t testing adequately, and aren’t monitoring to know when to roll back then you won’t realize these benefits.

How frequent should frequency be?

Folks like DORA have proven the correlation between deployment frequency and business success.

More seems to be better, but at a certain scale, your system starts to break down. A key limiting factor is how long it takes your pipeline to complete. If you are deploying more frequently than your total pipeline time, you run the risk of breaking the master. The potential for conflict arises when additional changes get merged while a pipeline is still running on a previous change. High velocity means everything can pass in staging but still fail in master. Very sophisticated engineering organisations like Google, Facebook and Uber mitigate this by building complex custom functionality to queue and sequence changes ensuring that once a pipeline starts, other code can’t get merged ahead of that change. At GitLab, we thought everyone deserved to be able to deploy at high velocity and keep master green. It’s why we have queueing and sequencing built-in as a feature called, ‘Merge Trains’.

CI/CD is a functional change, DevOps is a cultural one.

You can technically implement an automated system to build, test, and deploy, but that doesn’t mean your development and operations teams are collaborating on the end-to-end lifecycle or that you are continually learning and improving. I’d say CI/CD is a subcomponent of DevOps. DevOps is about people, process, and technology. A key technology enabling DevOps is CI/CD. The disruption is intertwined.

Once upon a time, GitLab was a code repository, but today GitLab is an entire DevOps platform. GitLab includes built-in Agile project planning, monitoring, application security, package management, Kubernetes management, a WebIDE, and more, all in addition to source code management and CI/CD.

In regards to effective CI/CD, the ability to run on multiple machines is a result of our CI/CD Runner architecture. Runners are the agents they do the work of each CI/CD job in a pipeline. You can have many Runners each on their own machine so you can run many jobs in parallel. Runners can even auto-scale to spin up new instances when additional capacity is needed and spin down when it’s not. This means when everyone commits their changes at 4pm on a Thursday in preparation of Friday sprint demos, your CI/CD platform can handle all of that work quickly, without anything waiting in a queue, and without having to pre-provision and pay for your peak capacity during the week.

CI/CD & CD

At GitLab we use CI/CD to mean continuous integration, delivery and deployment.

Choosing whether you want to deploy to production manually or automatically is simply a toggle in the configuration. Everything else about how you build your pipelines and use the product is the same regardless of which you choose. In fact, every job in a pipeline, not just your ‘deploy to prod’ job, can be either automatic or manual.

Your ruleset can even allow certain types of changes to go to production automatically while others require manual approval. Our design philosophy has been to build powerful small primitives that can be used as building blocks in diverse and flexible ways.

On the question of how functional tests differ from unit tests in CI/CD environments… the difference between unit and functional tests is the same whether those tests are automated or manual. Unit tests verify individual functions and methods in the code, while functional tests verify that actions return the expected results.

We also need to ask, if development teams use CI/CD tools to automate parts of the application build and construct a document trail, then what factors impact the wealth and worth of that document trail?

This is an interesting question, the most impacting factors are the compliance needs of the business and the scale at which they operate. In highly regulated environments, being able to produce a document trail can make the difference between passing or failing an audit. Similarly, a robust and accessible document trail significantly aids the troubleshooting process. When the system is down for 30 minutes, the value of the document trail differs depending on if you lost $100 during that 1/2 hour or $100,000.

From a technical perspective, the value of the document trail is based on how good of a trail it is. Do you have a single place to go to get all of your information, or are you having to cobble together a trail from data siloed in multiple different DevOps tools? Simplifying the toolchain is a key tactic for improving the usability and value of your records.

GitLab’s Lenny: positive about code from the start.