GitLab's latest release aims to enable complex continuous integration (CI) pipelines, team collaboration, and dependencies management across projects. Furthermore, GitLab 12.2 adds new push options for merge requests, and uses environment-specific Kubernetes namespaces to enable sharing the same cluster across multiple project environments.
To handle complex job dependencies in continuous integration pipelines, GitLab 12.2 introduces support for directed acyclic graph (DAG) dependencies:
Most typically this would cover when jobs need to fan in or out, and/or merge back together (diamond dependencies). This can happen when you’re handling multi-platform builds or complex webs of dependencies as in something like an operating system build or a complex deployment graph of independently deployable but related microservices.
Thanks to DAG support, developers will be able to define a job pre-requisite using the new needs: keyword. According to GitLab, this represents a significant step forward from sequential stages that were previously the only available mechanism to specify jobs dependencies. This also enables the concurrent execution of pipeline stages as soon as the jobs they require have been carried through.
Another new GitLab feature that aims to be useful for complex systems is the ability to manage cross-project dependencies for merge requests. This allows developers to specify in which order a given merge request should be applied when it includes changes that span across multiple projects. Such kind of scenarios are usually very tricky to handle and this often leads organizations to opt for consolidating multiple projects into one single repository, as it is that case with Microsoft consolidating their existing .NET repositories. Speaking further of merge requests, GitLab 12.2 supports a number of new push options, such as the possibility of changing the request title and removing the branch after merging it.
For developers using Kubernetes, GitLab 12.2 now provides a way to share the same Kubernetes cluster across different project environments, such as dev and stage each with its own set of permissions, to increase resource usage efficiency. This is made possible by using a dedicated Kubernetes namespace for each project environment, so you can map multiple environments to the same cluster with the guarantee that they will not collide. Using the same cluster basically means less reources are used and less book-keeping is required.
New in GitLab 12.2 are also additional collaboration facilities between developers and designers, although still at an experimental stage. Design management allows indeed to associate design assets, such as wireframes and mockups, to an issue, thus providing an easy way for different stakeholders, including designers, developers, and product managers, to collaborate around a single source of truth.
A number of additional new GitLab features that deserve a mention include the possibility to restrict group membership to users whose email address match a given domain name; the ability to roll out a new feature so it is only visible to specific users, thus enabling fine-grained control of who should be able to test that feature; mandating a security approval for certain merge requests; and more. For a full list, do not miss the official announcement.