A beginner's guide to continuous integration Close To search repositories and projects, login to gitlab.com . Suggestions GitLab Duo Agent Platform Code Suggestions (AI) CI/CD GitLab on AWS GitLab on Google Cloud Why GitLab? * Platform Execution & Workflows * CI/CD * Source Code Management * Agile Delivery Security & Governance * Application Security Testing * Governance & Compliance * Supply Chain Security Context & AI * Agentic Orchestration * Context Graph * Visibility & Measurement Explore the Platform Why GitLab One platform for speed with control across your software lifecycle. Learn more * Solutions Outcomes * DevOps Modernization * Security Modernization * AI Modernization By size * Enterprise * Small Business * Startups Industries * Financial Services * Public Sector * Telecommunications * Automotive * Education * Aerospace View all Solutions GitLab Transcend Catch our latest innovations announced at the last Transcend. Read the blog * Pricing * Resources Discover * Docs * University * Demo Series * Demo Hub * Services Connect * Blog * Community * Customers * Partners * Events View all resources What’s new in GitLab Stay updated with our latest features and improvements. Read the latest * Company * About * Jobs * Press * Handbook * Leadership * Investor relations * Trust Center * AI Transparency Center * Newsletter * Contact us * Talk to sales * Support portal * Customer portal Request a demo Get free trial Sign in Get free trial Ship at agent speed. Prove every step. Transcend returns on October 6. Register now Blog Engineering A beginner's guide to continuous integration Published on: January 22, 2018 7 min read A beginner's guide to continuous integration Here's how to help everyone on your team, like designers and testers, get started with GitLab CI. Riccardo Padovani CI/CD user stories At fleetster we have our own instance of GitLab and we rely a lot on GitLab CI/CD . Also our designers and QA guys use (and love) it, thanks to its advanced features. GitLab CI/CD is a very powerful system of continuous integration (CI) , with a lot of different features, and with every new release, new features land. It has very rich technical documentation , but it lacks a generic introduction for people who want to use it in an existing setup. A designer or a tester doesn’t need to know how to autoscale it with Kubernetes or the difference between an image or a service. But still, they need to know what a pipeline is , and how to see a branch deployed to an environment. In this article therefore I will try to cover as many features as possible, highlighting how the end users can enjoy them; in the last months I explained such features to some members of our team, also developers: not everyone knows what continuous integration is or has used Gitlab CI/CD in a previous job. If you want to know why continuous integration is important I suggest reading this article , while for finding the reasons for using Gitlab CI/CD specifically, I leave the job to GitLab itself. Introduction Every time developers change some code they save their changes in a commit. They can then push that commit to GitLab, so other developers can review the code. GitLab will also start some work on that commit, if GitLab CI/CD has been configured. This work is executed by a runner. A runner is basically a server (it can be a lot of different things, also your PC, but we can simplify it as a server) that executes instructions listed in the .gitlab-ci.yml file, and reports the result back to GitLab itself, which will show it in his graphical interface. When developers have finished implementing a new feature or a bugfix (activity that usual requires multiple commits), they can open a merge request, where other members of the team can comment on the code and on the implementation. As we will see, designers and testers can also (and really should!) join this process, giving feedback and suggesting improvements, especially thanks to two features of GitLab CI: environments and artifacts. CI/CD pipelines Every commit that is pushed to GitLab generates a pipeline attached to that commit. If multiple commits are pushed together the pipeline will be created for the last one only. A pipeline is a collection of jobs split in different stages. All the jobs in the same stage run concurrently (if there are enough runners) and the next stage begins only if all the jobs from the previous stage have finished with success. As soon as a job fails, the entire pipeline fails. There is an exception for this, as we will see below: if a job is marked as manual, then a failure will not make the pipeline fail. The stages are just a logical division between batches of jobs, where it doesn’t make sense to execute the next job if the previous failed. We can have a build stage, where all the jobs to build the application are executed, and a deploy stage, where the build application is deployed. Doesn’t make much sense to deploy something that failed to build, does it? Every job shouldn’t have any dependency with any other job in the same stage, while they can expect results by jobs from a previous stage. Let’s see how GitLab shows information about stages and stages’ status. What is a CI job? A job is a collection of instructions that a runner has to execute. You can see in real time what the output of the job is, so developers can understand why a job fails. A job can be automatic, so it starts automatically when a commit is pushed, or manual. A manual job has to be triggered by someone manually. This can be useful, for example, to automate a deploy, but still to deploy only when someone manually approves it. There is a way to limit who can run a job, so only trustworthy people can deploy, to continue the example before. A job can also build artifacts that users can download, like it creates an APK you can download and test on your device; in this way both designers and testers can download an application and test it without having to ask for help to developers. Other than creating artifacts, a job can deploy an environment, usually reachable by an URL, where users can test the commit. Job status are the same as stages status: indeed stages inherit theirs status from the jobs. Artifacts As we said, a job can create an artifact that users can download to test. It can be anything, like an application for Windows, an image generated by a PC, or an APK for Android. So you are a designer, and the merge request has been assigned to you: you need to validate the implementation of the new design! But how to do that? You need to open the merge request, and download the artifact, as shown in the figure. Every pipeline collects all the artifacts from all the jobs, and every job can have multiple artifacts. When you click on the download button, a dropdown will appear where you can select which artifact you want. After the review, you can leave a comment on the MR. You can also always download the artifacts from pipelines that do not have a merge request open ;-) I am focusing on merge requests because usually that is where testers, designers, and shareholders in general enter the workflow. But merge requests are not linked to pipelines: while they integrate nicely with one another, they do not have any relation. CI/CD environments In a similar way, a job can deploy something to an external server, so you can reach it through the merge request itself. As you can see, the environment has a name and a link. Just by clicking the link you to go to a deployed version of your application (of course, if your team has set it up correctly). You can also click on the name of the environment, because GitLab also has other cool features for environments, like monitoring . Conclusion This was a small introduction to some of the features of GitLab CI: it is very powerful, and using it in the right way allows all the team to use just one tool to go from planning to deploying. A lot of new features are introduced every month, so keep an eye on the GitLab blog . For setting it up, or for more advanced features, take a look at the documentation . In fleetster we use it not only for running tests, but also for having automatic versioning of the software and automatic deploys to testing environments. We have automated other jobs as well (building apps and publishing them on the Play Store and so on). About the guest author Riccardo is a university student and a part-time developer at fleetster . When not busy with university or work, he likes to contribute to open source projects. An introduction to continuous integration was originally published on rpadovani.com. Cover photo by Mike Tinnion on Unsplash Share this article Stay in the know with GitLab's monthly newsletter All fields required More to explore View all blog posts Engineering Co-Create: Building GitLab with our users Read the blog Engineering Git was built for humans — agents need an upgrade Read the blog Engineering From chaos to context: Building an AI dev workflow Read the blog We want to hear from you Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback Start building faster today See what your team can do with the intelligent orchestration platform for DevSecOps. Get your free trial Contact sales ® Footer links Pricing * View plans * Why Premium? * Why Ultimate? Contact Us * Contact sales * Support portal * Customer portal * Status * Terms of use * Privacy statement * Platform * Explore the platform * Agentic Orchestration * CI/CD * Context Graph * Why GitLab Topics * CI/CD * GitOps * DevOps * Version Control * DevSecOps * Cloud Native * AI for Coding * Agentic AI Solutions * DevOps modernization * Security modernization * AI modernization * Financial services * Public sector * Telecommunications * Automotive * Education * Aerospace * Enterprise * Small business * Startups * GitOps * Software composition analysis * Value stream management * All solutions Resources * Install * Quick start guides * Docs * University * Demo Series * Demo Hub * Services * Blog * Community * Customers * Partners * Events * Newsletter * What's new * All resources Company * About * Jobs * Press * Handbook * Leadership * Investor relations * Trust Center * AI Transparency Center * Sustainability * Diversity, inclusion and belonging (DIB) * Modern Slavery Transparency Statement * * * * Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license View page source Edit this page Please contribute © 2026 GitLab Inc.