Continuous Integration is an important part of any software development pipeline. It must be easy to use, reliable, and accurate in terms of results, so that's the core of where we focus for CI. While we are very proud that GitLab CI/CD is recognized as the leading CI/CD tool on the market, as well as a leader in the 2019 Q3 Cloud Native CI Wave, it's important for us that we continue to innovate in this area and provide not just a "good enough" solution, but a great one.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
There are a couple related areas you may be looking for:
Our single next most important item is adding a control to your projects, ensuring only the appropriate team members are able to edit the .gitlab-ci.yml (gitlab#15632). This will help teams ensure control over who is able to implement changes to the build and release process, an important consideration for larger organizations. This is being built as a special case of gitlagb#14376, which implements the ability to host the .gitlab-ci.yml outside of the repository, so in this way we're getting two great features at once.
Since this category is already at the "Lovable" maturity level (see our definitions of maturity levels), and it is important to us that we defend that position in the market. As such, we are balancing prioritization of important P2 issues and items from our backlog of popular smaller feature requests in addition to delivering new features that move the vision forward. If you feel there are any gaps or items that would risk making GitLab no longer lovable for you, please let us know by contacting Jason Lenny (PM for this area) with your ideas.
One major area of focus and expansion is around these two important types of pipeline use-cases. Monorepos are where you put all of your projects into a single repository, and cross-project piplelines (taken to an extreme) are where you might put every service in a microservice architecture into different repositories. There are pros and cons to each approach, but we want to be sure GitLab effectively supports both.
To be more competitive we are considering gitlab#10107 to move GitLab CI/CD for External Repos (GitHub + BitBucket) from Premium to Starter. This will help more teams have access to GitLab CI/CD, and is potentially a great way to introduce more people to GitLab in general, but also comes with costs of running the CI/CD so the decision needs to be weighed closely against the opportunity.
The most urgent gap that we want to address in competing with Microsoft is the capability to have Windows Runners as part of our shared fleet. This is technically part of our runner category vision but is a critical unlock for CI in general.
GitHub is evolving Actions into more and more of a standalone CI/CD solution. GitLab is far ahead in a lot of areas of CI/CD that they are going to have to catch up on, but Microsoft and GitHub have a lot of resources and have a big user base ready and excited to use their free product. Making an enterprise-ready solution will take some time, but they are no doubt actively working on closing these gaps.
Actions itself is still early days. At first blush it's nice that there are small, individually contributed pluggable modules that can do different things. There's some question, though, as to how this will scale over the medium term. The semi-distributed, event-based interaction model poses some risk of emergent pipeline behaviors becoming difficult for a human to understand, but does provide some nice flexibility in terms of relating how different events in the system can trigger different responses. Similarly, it is yet to be seen how they will avoid the Jenkins issue where many different behaviors (plugins as analog to actions) will be maintained over time (or not) by the enterprises who depend on them, and how these will be compatible with each other as complexity increases over time. There are also potential security concerns with maliciously controlled actions running code as part of your pipelines; in ecosystems where using lots of small packages from different authors is normalized (i.e., NPM) auditing and scanning to mitigate this can become burdensome.
They are planning to bundle in secrets management, and we are also exploring this in our Secrets Management category. We also have a Package Management category which is analogous to GitHub Packages. Continuous Delivery elements can be found in our Continuous Delivery category.
Microsoft has also provided a feature comparison between Azure DevOps (though not GitHub CI/CD) and GitLab which, although it is not 100% accurate, highlights the areas where they see an advantage over us. Our responses overall as well as to the inaccuracies can be found in our comparison page.
Jenkins has become an industry punching bag for selling DevOps software (just saying "my product solves the same problems as Jenkins, but without the huge expensive legacy mess" gives you the keys to the kingdom.) Jenkins is trying to address this by splitting their product into multiple offerings, giving them the freedom to shed some technical and product debt and try to innovate again. They also acquired CodeShip, a SaaS solution for CI/CD so that they can play in the SaaS space. All of this creates a complicated message that doesn't seem to be resonating with analysts or customers yet.
BitBucket pipelines has been Atlassian's answer to a more integrated CI/CD approach than Atlassian Bamboo, is UI driven, and enables users to build and deploy code by creating YAML based configuration files. On February 28, 2019, Atlassian announced Bitbucket Pipes as an evolution of Bitbucket pipelines and gained a lot of press around Atlassian taking on GitHub/Microsoft. While it is early in the evolution of this as a product in the enterprise market, there are a number of interesting patterns in the announcement that favor Convention over Configuration.
CodeFresh follows a similar container-based plugin model as GitHub Actions, so our approach is similar to the one written above in response to that solution.
There are a few key findings from the Forrester Research analysts on our CI solution:
To continue to drive innovation in this area, we are considering gitlab#20306 next to add Vault integration throughout the CI pipeline. This builds off of work happening on the Configure team and will allow for a more mature delivery approach that takes advantage of ephemeral credentials to ensure a rock solid secure pipeline.
The most popular Customer Success issues as determined in FQ1-20 survey of the Technical Account Managers were:
Our most popular customer issue is to add an option to keep only the latest artifact in each branch (gitlab#16267), followed by child parent pipelines (gitlab#16094), and then cross-project artifact dependencies (gitlab#14311). All of these are scheduled for upcoming releases.
Other items with a lot of intention include normalizing job tokens in a more flexible way, so that they can have powerful abilities when needed and still not introduce security risks (gitlab#20416),
We also have a few issues about making variables avaiable before includes are processed, however there is a "chicken and egg" problem here that has been difficult to solve. Child/parent pipelines solves some use cases, but not all, and in the meantime we are continuing the discussion in issues like gitlab#24811 and gitlab#1809. If you're interested in technical discussion around the challenges and want to participate in solving them, please see the conversation here.
Supporting CI configuration definition outside of the repository is currently our top internal customer issue: gitlab#14376. Other top internal customer issues include:
needs to specify a job that can be started immediately (gitlab#30631).gitlab-ci.yml outside of repository (gitlab#14376)Our most important vision items are our follow ups for the Directed acyclic graphs (DAG) for pipelines MVC gitlab-org#1716, which will allow for out of order execution and open a world of new possibilities around how pipelines are constructed.
Cross-project triggered-by registry image change is also an interesting one for our vision, which would add the ability to depend on container image changes in another project instead of pipelines. This could be a nicer, container-first way of working.
