このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
Continuous Integration is an important part of any software development pipeline, and part of the Verify stage here at GitLab. CI must be easy to use, reliable, and accurate in terms of results, so that's the core of where we focus. While we are very proud that we are 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.
You may also be looking for one of the following related product direction pages: GitLab Runner, Continuous Delivery, Release stage, or Jenkins Importer.
We're working now on delivering our most popular customer issue, the ability to keep only the latest artifact in each branch (gitlab#16267).
Our new (dynamic) child/parent pipelines feature is also getting some attention with three major MVCs in progress:
.gitlab-ci.ymlSince 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.
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 large user base excited to use their product, especially when given away as part of a package. Actions has a more event-driven and community plugin-based approach than GitLab, which is more declarative and where we take community contributions directly into the product where they can be maintained, rather than something closer to the Jenkins plugin model with community maintained Actions.
Time will tell if distributed CI ends up being more powerful, or just harder to reason about, and if they are able to avoid the same trap of unmaintained community Actions that companies became dependent on that Jenkins ran into. Regardless, we're monitoring and bringing the best of their innovation into our product. We've already had some successes running GitHub Actions directly in GitLab CI and will continue to explore that. We are also working on a migration guide to help teams we're hearing from who are looking to move over to GitLab have an easier time. Features like making the script section in containers optional would make it easier to build reusable plugins within GitLab that would behave more like Actions.
Jenkins is largely seen as a legacy tool, and most people we speak with are interested in moving off to something more modern. We are addressing this with our Jenkins Importer category which is designed to make this as easy as possible.
There are other CI solutions in the market, but the majority of the conversation is between us, Jenkins, and Actions at this point. Atlassian has built BitBucket Pipelines, a more modernized version of Bamboo, which is still in the early stages. Microsoft is maintaining (at least for now) Azure DevOps at the same time as GitHub. CodeFresh and CircleCI have both released container-based plugin model, similar to GitHub Actions. CircleCI in particular is known for very fast startup times and we're looking to ensure we keep up or get even faster.
There are a few key findings from the Forrester Research analysts on our CI solution. GitLab is seen as capable as the solutions provided by the hyperclouds themselves, and well ahead of other neutral solutions. This can give our users flexibility when it comes to which cloud provider(s) they want to use. We are also seen as the best end to end leader, with other products not keeping up and not providing as comprehensive solutions. What this tells us is that it is important for us to continue to innovate and make it hard or even impossible for competitors to maintain pace.
As such, our path to improving our analyst performance matches our solutions above in terms of staying ahead of our competitors.
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, our sales team has requested a Jenkins importer in order to make migrating to GitLab easier: this is being delivered via the Jenkins Importer category, but is mentioned here for completeness.
Our top five customer issues (search) include the following:
needs: (DAG) to refer to a job in the same stageAnother item with a lot of attention is to normalize 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. There are two related epics here, Use a variable inside other variables in .gitlab-ci.yml and Raw (unexpanded) variables MVC
Our top five internal customer issues (search) include the following:
needs: (DAG) to refer to a job in the same stage$ character in build variableswhen:manual within triggered pipelinesOur top three dogfooding issues (search) are:
With the beta release of the Directed Acyclic Graph (DAG) pipeline visualization, 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 have a set of other follow ups as well for the DAG 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 an epic to improve the rules syntax at gitlab-org#2783, as well as one for making improvements to the CI Linter to provide more helpful warnings and links to documentation. Making it easier to use CI with external repositories is also on the radar. We also have an epic focused on improving the .gitlab-ci.yml authoring experience in a number of ways, which is related to another epic specifically focused on improving editing the .gitlab-ci.yml from within the Web IDE.
Looking further into the future, we have plans around supporting ML/AI technologies as part of (or being built by) GitLab CI.