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. Our focus in the next three years relates to the goals for the Verify stage.
There are a couple related areas you may be looking for:
With the release of the DAG visualization in beta, we are now collecting feedback in gitlab#220368 for the next iteration of this feature for making it easier to trace the relationship between dependent jobs.
We also want to help you author better CI yaml files with improvements to the CI Linter that provides helpful warnings and links to documentation to prevent your pipelines from breaking.
For when you need a simple way to generate parallel jobs, we are making it possible to define a cartesian product/matrix for build jobs in gitlab#15356. This is perfect for scenarios when you just need to create jobs based on a simple matrix and you don’t need the more powerful custom behaviors that parent/child pipelines are intended to handle.
Since this category is already at the "Lovable" maturity level (see our definitions of maturity levels), 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 Thao Yeager (PM for this area) with your ideas.
There are a few key competitors that we are tracking for CI:
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 feature is now available in beta, and we are working towards our general launch. Additional details can be found on our runner category vision.
GitHub has evolved Actions into more and more of a standalone CI/CD solution. GitLab remains 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.
There are two main elements to Actions that are comparable to GitLab. The first is the event-based nature which allows for flexible wiring of components together, even across systems. In some ways this is powerful and allows you to quickly set up different integrated workflows that can trigger based on different things happening in the system. We do provide some of the same events, but not complete flexibility. It remains to be seen if this ends up being a stable long term way to manage a CI system, however, since stability, auditing, and so on are so important, for now we are monitoring.
The other element is the suite of open source individual Actions that perform single tasks, and are embeddable within pipelines. This comes with some of the downside of the Jenkins plugin ecosystem where you are depending on maintainers and others out of your purview, but because Actions is new it has for the moment a ton of engaged people actively producing and maintaining them. CircleCI offers something very similar with Orbs. At the moment we are investigating options here, including making it easy for Actions or Orbs to run on GitLab and/or working on an open standard.
Microsoft has 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 gained a reputation for being original innovators, but now dated and bound to legacy concepts and code. They have recognized this and are trying to address the issue 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 so far creates a complicated message that doesn't seem to be resonating with analysts or customers yet.
For our part, we are also investigating making it easy to import or use your Jenkins jobs in GitLab.
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 seem to 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.
CircleCI Orbs are also essentially the same as GitHub Actions, so for our response thre please see above. The other thing that CircleCI is great at is fast availability of Runners, as well as startup time. How we are working to improve this can be found on our runner category vision.
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#28321 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 was filtering pipelines by status or branch. Also important for the sales team is gitlab#205494 which will allow for easier use of GitLab's security features when not using GitLab's CI.
In addition to features, a Jenkins importer has been requested to make getting up and running quickly easier: this is being delivered via the Jenkins Importer category.
Our most popular customer issue is to add an option to keep only the latest artifact in each branch (gitlab#16267). Another item 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#3559),
We also have a few issues about making variables available 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 the issue gitlab#1809. If you're interested in technical discussion around the challenges and want to participate in solving them, please see the conversation here.
Other important customer issues include:
Our top internal customer issues include the following:
An emerging trend in the CI/CD customer base is better administration of items shared across projects. We are attempting to solve this pain in gitlab#199739 with a CICD group dashboard, while also addressing some issues in the Release stage. Also related is enabling viewing group-level secret variables at a project level in gitlab#18978.
We continue to iterate on the three major pipeline features that can be mixed and matched with continued efforts to mature these:
We have a set of 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. We have a similar epic to improve parent/child pipelines at gitlab-org#2750 and an epic for the rules syntax at gitlab-org#2783.
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.
