Four Steps to Set Up a CI/CD Pipeline in 20 Minutes
Software feels the need for speed. Continuous integration and continuous deployment promise speed (and better quality) but simply installing the pipeline isn’t enough. CI/CD requires continuous improvement in order to make sure you’re getting the most out of your software development lifecycle. Here are four steps we’ve taken to ensure our CI/CD pipelines are moving swiftly and efficiently. Follow along to fine-tune your process.
Learn the Basics First
In order to make sure you get the most out of your CI/CD pipeline you first have to understand the many moving parts. This is a simple step to take but it is vital that everyone involved has a firm grasp on the terminology.
It all starts with a pipeline, which is a collection of jobs split into different stages. A code change is normally known as a commit, and a job just refers to instructions that a runner has to execute. A runner is an agent or server that executes each job individually. Runners can be spun up or down as needed thanks to the beauty of microservices and Kubernetes cluster architectures. And then there are stages, which refer to the different processes of a job like build or deploy. Jobs in the same stage can be done in parallel.
A CI/CD pipeline is configured using a YAML file. You’ll want to set the parameters of the pipeline: what to execute and what happens when a process succeeds or fails. Complex projects with dependencies in multiple areas (microservices are a good example) will require a multiproject pipeline.
Finally, there are a handful of broader terms you’ll need to adapt for any CI/CD pipeline you’re working on. Version control tracks changes over time and can make it easy to switch back to an earlier version if necessary. Audit trails track source code changes. Collaboration, in this context, refers to how easy it is for the entire team to have access to the code for improvements, suggestions, and updates. And a Lint tool helps ensure the YAML files are valid and can be helpful to new users.
Put It on Autopilot
You already know that CI/CD is a simple term for a very not simple process. In fact, most CI/CD pipelines have at least nine steps and often many more. But we’ve proved at GitLab how it was possible to get a pipeline up and running in under 20 minutes and our secret ingredient was what we call Auto DevOps. Choosing a CI/CD solution with built-in automation simplifies everything.
In that short span of time, we built an application into a container, checked it for vulnerabilities, dependencies and licenses; deployed it to a Kubernetes cluster and set up hostnames as well as DNS and TLS certifications (that were automatically renewed if necessary). Finally, the code was performance tested. Want to try this at home? Here’s the code you need to easily connect to Kubernetes: kubectl gitlab-bootstrap gitlab-project-id. The result is a URL that you can follow to see more about the Kubernetes cluster in your GitLab project.
But that’s also not to say that everything has to be automated in every situation. The underlying source code should be available to you for each component of the deployment process so you can decide which jobs make sense to automate.
Stop Waiting for Builds
Nothing is more annoying (and time-wasting!) than sitting around waiting for the pipeline to run. But there is a solution: autoscaled runners. Autoscaling brings flexibility and real-time supply and demand to a CI/CD pipeline like nothing else. And it can virtually eliminate that pipeline downtime if you do it right.
To get started you’ll need an instance and a runner ours is free and written in Go so it can run on any platform where you can build Go binaries including Linux, OSX, Windows, FreeBSD and Docker). You’ll want to configure your runners so that machines are created on-demand. After a job is completed your runners can wait for the next job or be removed automatically. It’s also possible to spell out how long you’d like them to hang around, the “IdleTime,” before they’re shut off. With autoscaled runners, nothing is wasted. Your infrastructure will have achieved Goldilocks status — not too much, not too little but just right for your needs.
Autoscaled runners let developers focus on writing code and frees operations pros from infrastructure worries. It’s an easily achievable win-win.
Streamline the Process
Nobody is lucky enough to be able to write code in a vacuum, unfortunately. So developers have to be certain new code doesn’t stomp all over any dependent microservices and that means more testing. The most efficient way to accomplish all the required testing is by setting up a cross-project pipeline.
It’s a straightforward process that involves simply triggering cross-project pipelines when you create your project pipeline. In GitLab it’s possible to just a trigger job in the CI config file. Adding the “trigger” keyword to the YAML CI file, which outlines the order of the CI/CD stages, will set off a bridge job that creates cross-project pipelines. It’s possible to set up parameters in those downstream pipelines and define which branches to use.
If you’re worried about being able to track what is going on with all the sequential and parallel jobs and then downstream pipelines as well, pipeline graphs offer a visual guide to all of the moving parts.
Don’t let your tools slow you down. Join GitLab for our Mastering CI/CD webcast. Click here to watch.