Blog Company GitLab CI/CD's 2018 highlights
Published on: January 21, 2019
8 min read

GitLab CI/CD's 2018 highlights

We move quickly, always with an eye to the future, but let's take a moment to look back on how GitLab CI/CD has evolved in the past six months.


Hello everyone, and happy New Year! For those who don't know me, my name is Jason Yavorska and I've been the product manager of GitLab CI/CD since around the middle of last year. 2018 was a big year for CI/CD improvements in GitLab, and I'm so proud of our team and what we've been able to deliver in partnership with you, our users. Even just looking back on the last six months of improvements, we've delivered a ton of changes that move our vision for CI/CD forward, address important asks from our users, and build the foundation for an amazing 2019.

Below are a few of the highlights from my time here so far; be sure to let me know in the comments if I missed something that meant a lot to you.

Access control for GitLab Pages

One of the most amazing things about working for an open core company like GitLab is that our community of users can play an outsized role in how our product grows and develops, thanks to their always impressive contributions. Last year we introduced Access control for Pages (11.5), a feature with 304 πŸ‘ that was actually part of our 2019 vision, and was built thanks to a significant community contribution from MVP Tuomo Ala-Vannesluoma.

This was not just a great feature, but also highlights how GitLab and community contributors can work together to do amazing things. It came out shortly after I joined as a new product manager here, and it really opened my eyes to the possibilities inherent in working together transparently and openly with our user community. Now I don't think I could ever go back to any other way of working.

Feature flags

I'm always looking for ways to expand our horizons and bring more great capabilities into the CI/CD space, and the team achieved that last year with Allow users to create and manage feature flags for their applications (11.4). A major piece of our 2018 vision, feature flags are so important to continuous delivery workflows since they allow you to safely isolate delivering your code to production, from the moment users engage with it, giving you more control and better options when it comes to how and when you deliver software.

CI/CD feature flags

Pipelines for merge requests

Sometimes, what you do in one year may be valuable on its own, but it also helps establish a foundation for more in the future. A common request from the community last year had been to make pipelines more aware of merge requests, so that at runtime, information such as the target branch, merge request name and ID, and other information was available to the pipeline. In 2018 we introduced only/except: merge_requests for merge request pipelines (11.6), which created this linkage. One great way to take advantage of this feature already is to use it to only create Review Apps on merge requests, helping to save money on environments versus creating them for every pipeline.

Perhaps even more exciting than this feature on its own, is that it will continue to evolve and grow into the ability to Run a pipeline on what the merged result will be. I can already say with confidence that this will be a game changer for teams that want to prioritize keeping their master branch green. As far as predicting the future outside of GitLab, I'm still accepting merge requests for that πŸ˜‰

pipelines for merge requests

Usability improvements for the merge request widget

Speaking of merge requests, in general the team has made a lot of improvements to how the merge request widget interacts with CI/CD. We added JUnit XML Test Summary (11.2), part of our 2018 vision to make testing a more interactive part of the CI pipeline. We also now Show enhanced information on running deploys (11.5), and Link directly to changed pages in Review App (11.5), which uses Route Maps to send you directly to the updated content. Both of these changes were welcome improvements that made it much easier to see what was going on, all in one place.

CI/CD review app link


#movingtogitlab was an exciting movement in 2018, and I wanted to ensure a great experience for everyone checking us out, even if they were just trying out GitLab CI or other features, and still using GitHub for repositories. One of the challenges that people ran into early on was the way status checks were named by GitLab CI, which didn't play nicely with the way GitHub expected them to work. The team was able to introduce Name status checks consistently to support GitHub-integrated CI workflow (11.5) as a change to unblock this, ensuring a valuable experience for everyone, even if you weren't ready to go "all in" on GitLab yet.


Here at GitLab, we take stewardship of open source seriously. I was very happy to move the include: keyword from paid to free, because I know how important it is for CI/CD users to support proper reuse instead of copy-pasted code. Move "include external files in .gitlab-ci.yml" from Starter to Core (11.4) (with a grand total of 267 πŸ‘ on the issue) achieved this, and opened up new doors, not just for avoiding duplication, but also for more secure ways of implementing common workflows by moving compliance, security, and governance job implementation to a centrally controlled location.

Honorable mentions

There wasn't enough time to cover everything in this post without making it a mile long, but there are a few other honorable mentions I want to call out:

What's next?

Of course, the mission to improve GitLab CI/CD doesn't stop here. We're bringing Brendan O'Leary on board as the full-time product manager for CI (what we call the Verify stage), freeing me up to focus entirely on CD (what we call Release). We're also significantly growing headcount for the engineering teams supporting us. Having full-time product managers and larger teams dedicated to each of these stages is going to allow us to deliver even more amazing things, even faster.

I've touched on a couple points above, but tried to avoid making this a preview of what's coming for CI/CD in 2019. If you're interested in where Brendan and I are headed, you can visit our direction pages for Verify (CI) and Release (CD), and feel free to reach out to us directly if you'd like to have a conversation – we'd love to chat about your ideas. Being a transparent, open core company, we also welcome participation in all of our public issues (which you'll find linked to from the above direction pages). For me, the best part of this job is interacting with you, the users of GitLab, so thank you for that opportunity. Here's to another great year of working together to make the job of delivering software fun and rewarding!

Just one more thing...

I'd be remiss if I didn't mention how great GitLab is as a place to work. If you're interested in joining our all-remote team, we're constantly growing and looking for great PMs and others to join us. Check out our jobs page to learn more. I'd encourage you to apply even if you don't see an exact match – GitLab is great at finding the right fit for the right personality, even if that's not exactly listed on our hiring website. If you're really unsure, feel free to reach out to me directly (@j4yav) and I'll help you get in touch with the right person.

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

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert