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.
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 😉
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.
#movingtogitlab
#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.
Stewardship
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:
- 11.2: Manually stopping environments (with 245 👍 from our users) added the ability to manually stop your environments, such as review apps, instead of only through pipeline automation.
- 11.3: Improve handling of includes in
.gitlab-ci.ymlto better enable script reuse/templates introduced a new way toextendyour job definitions using templates, including from across different files. - 11.4: Run jobs only/except when there are changes for a given path or file (with a whopping 424 👍) gave you the ability to control whether a job runs or not, based on which files were changed.
- 11.4: Add support for interactive web terminal to Docker executor let you connect an interactive to a build/deploy environment and troubleshoot on the live runner host.
- 11.4: Add timed deployments to AutoDevOps incremental rollouts enabled new deployment strategies where the rollout was done over time in phases.
- 11.5:
paralleljob keyword to speed up pipelines added an easy way to run parallel instances of a job without creating duplicate jobs in yourgitlab-ci.yml. - 11.6: Allow pipelines to be deleted by project owners (265 👍) gave control over removing old and invalid pipelines, as well as those which may have accidentally included sensitive information in the outputs.
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.
