GitLab 11.0 released: Auto DevOps and license management
- Transfer
Creating high-quality software is not an easy process. First, you need to solve business problems and write quality code. However, this does not end the complexity: you need to make sure that your code works quickly, safely and reliably. Working with code is a pipeline of many steps, such as assembly, integration, testing, security, review, configuration, and deployment. To perform all these actions takes a lot of time and effort.
In addition to providing opportunities for collaboration in public and private repositories, GitLab also simplifies the entire development process with the help of an extensive built-in, and from this version, also an automated set of tools. Just commit your code, and Auto DevOps will do the rest. Auto DevOps is a pre-assembled full-fledged CI / CD pipeline that automates the entire delivery process. Auto DevOps is released to the public (GA, General Availability) in GitLab 11.0.
Other key GitLab 11.0 innovations:
- License management , which automatically finds licenses by dependencies of your projects;
- Improved security testing of your code, containers and dependencies;
- New integration with Kubernetes ;
- Improved Web IDE ;
- Improved display of epic and road maps ;
- Incremental deployment ;
- And much more.
First, let's go through this list in more detail.
Auto DevOps covers the entire delivery cycle: Just commit your code to GitLab and let Auto DevOps do the rest: this system will build , test , verify code quality , security and licenses , package , test performance , deploy and monitor your application.
“GitLab is a key component in our development and delivery processes, thanks to which we have increased our delivery speed four times and seriously simplified the joint development process in our teams,” said Chris Hill, lead systems engineer at the infotainment department at Jaguar Land Rover.
“We are very pleased with Auto DevOps, because it allows us to focus on code writing and business processes. The rest is handled by GitLab: automated builds, testing, deployment, and even monitoring of our application. ”
License management (analysis of software components): Often, software is a complex interweaving of code with third-party components (libraries, frameworks and various tools). Each component typically has licensing restrictions and permissions that need to be monitored and taken into account. In GitLab 11.0, we add License Management functionality (software component analysis). It will be built into Merge Requests, from where you can track the licenses of your components.
Security: We continue to work on improving the built-in security features of GitLab. Now you can find vulnerabilities even earlier with built-in static and dynamic application testing, as well as dependency scanning and containers. We have expanded the coverage of static application security testing (SAST) - now it is supported for Scala and .Net . We also added new elements to the SAST reports, now they will provide you with even more details.
Kubernetes: We continue to improve our integration with Kubernetes and to simplify the interaction of GitLab with this system. In this release we have added several new features, the most interesting of which is the ability to view Kubernetes pod logs directly from the GitLab deployment board.
GitLab Web IDE: The more you can do without leaving the IDE, the more productive you work. Now you can view the CI / CD pipelines directly from the IDE , so you can see the instant report in case of unsuccessful execution of the pipeline. In addition, we added the ability to quickly switch to the next merge-request, which will allow you to create, improve or review merge-requests without leaving the IDE. All this will allow you to quickly and efficiently participate in making changes to the code and reviewing them.
Epic and Roadmap Navigation: For improved visualization of the progress of epic and roadmaps, it may be useful to change the scale of timelines, which will provide a more general overview and simplify their planning. Therefore, we have added this feature to their navigation interface.
( MVP ) of this month - Vitaliy 'blackst0ne' Klachkov
Vitaly made a great contribution to the development of GitLab and has already been named MVP several times this year. For version 11.0, he did serious work on updating the technical side of GitLab: Vitaly translated most of the remaining Spinach tests to RSpec, and also put a lot of effort into improving GitLab for Rails 5. In addition, after we decided to add compression functionality and Merge commits (squash and merge) in GitLab Coer and GitLab.com free, Vitaly took this job and finished it to the release of this release. Here is a list of all the tasks that he performed for GitLab 11.0 .
Thanks again, Vitaly! Soon you will receive another package with gifts!
Key innovations GitLab 11.0
Auto DevOps goes public (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The first beta of Auto DevOps was added to GitLab 10.0 . And in GitLab 11.0, Auto DevOps goes public (Generally Available). Auto DevOps requires minimal configuration and does all the work on your project from the build stage to production and monitoring.
Auto DevOps uses DevOps best practices: it configures your build, test, code quality, static and dynamic security testing, dependency scanning, license management, container scanning, Review Apps, browser performance testing, deployment and monitoring - all in one application. The use of this functionality simplifies the transition to DevOps of new teams, because it allows you to start working with a solid functioning pipeline.
Auto DevOps allows developers to focus on what is most important for their organization - the delivery of quality code.
Our updated quick start guide for Auto Devops can be found here .
Conveyor statuses and information about CI / CD work in Web IDE (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Continuous Integration (CI) is an important step in the delivery of high-quality software. Now you can find out the CI status of the current commit by simply looking at the status window in the bottom left corner of the Web IDE. Moreover, on the right you can look at the status and logs of each work. This simplifies work on merge-requests with unsuccessful CI passing, since you can open the failed work on one screen and the file you are working on now.
Previously, in such situations, you had to open several tabs and switch between them, and now all the necessary information is available directly in the Web IDE. In the future, we plan to add the ability to preview and test changes before a commit.
Switching between Merge Requests in Web IDE (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
It is easy to imagine a situation in which one person works on multiple merge-requests in several projects at the same time. Now you can switch between your (assigned to you and created by you) merge-requests in one click. It doesn’t matter whether you are reviewing someone else’s merge request or working on your own - thanks to this innovation you can spend more time on code and less on searching.
License Management (ULTIMATE, GOLD)
In the realities of modern software development, most applications use third-party components to perform certain functions; This approach allows you to not start each project from scratch. Therefore, third-party libraries are so common, often they are directly supplied by package management services like RubyGems and npm. However, with this approach, you need to ensure that the licenses of third-party components are compatible with your application, because conflicting licenses can lead to legal problems.
To solve such problems, we add license management functionality to GitLab 11.0. It automatically passes through all dependencies in your projects and aggregates their licenses. New licenses are displayed in the merge-request widget before they become part of the main branch.
If you use Auto DevOps , license management is automatically enabled for your projects. You can also enable this functionality manually for custom definitions .gitlab-ci.yml.
License Management Documentation
SAML authorization at the group level (beta) (PREMIUM, ULTIMATE, SILVER, GOLD)
Competent user data management is a must for large organizations. Often, for this purpose, an identity provider is used, which works with all user data, so we added Security Assertion Markup Language (SAML) support for groups.
Now group owners will be able to set up an authentication service for the group and provide users with a single authorization link (SSO). This made it possible to manage the authorization and personal data at the group level, which can be useful in cases where the general SAML instance does not satisfy all the requirements of the group.
This innovation is especially useful for GitLab.com groups, in which you can now configure the identification service for use in the enterprise.
New navigation themes (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
With the release of GitLab 10.0, we did a major navigation update , and in version 11.0 we add some new themes for it. Now you have even more opportunities to personalize your interaction with GitLab.
We have added a completely new red theme, as well as a light version for all existing themes.
Profile Settings Documentation
Other GitLab 11.0 improvements
Compress and merge commits in GitLab Core and GitLab.com Free (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When working on a large-scale innovation, developers often push multiple commits into the work branch, and the number of these commits can only increase in the process of reviewing the code. Many teams prefer to compress these commits into one before merge with the master branch. This allows you to maintain the readability of the Git history , which will seriously simplify the review of code changes in the future.
Compression (squash) is part of the git functionality, so developers can run this command on their computer directly in front of merge. However, GitLab simplifies this process even more: you can compress and merge in one click directly from the web interface. For example, accompanying repositories can now compress commits without contacting the change author, which speeds up and simplifies the workflow.
Previously, this functionality was only available at GitLab Starter, GitLab.com Bronze and at higher levels. However, many users have told us that this feature will be useful for all subscription levels, so now it goes into open access and becomes available in GitLab Core and GitLab.com Free!
Thanks to blackst0ne for his contribution to this work!
Documentation on compression and merge commits
Opening projects in Xcode (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
At the WWDC in June, Apple announced the integration of Xcode with GitLab , which will undoubtedly simplify working with Xcode projects on the GitLab host.
GitLab now supports cloning projects containing files .xcodeprojor .xcworkspaceby clicking the “Open in Xcode” button. When viewing Xcode projects in the GitLab interface, this button will be located next to the Git URL for cloning.
Documentation for opening projects in Xcode
Date ranges for road maps (ULTIMATE, GOLD)
Since there are no restrictions on the dates of the beginning and end of the epic, we decided to add the possibility of finding epic on time ranges.
In this release, we add date range functionality for road maps. Now you can search for epics by quarters, months and weeks. Weekly search can be useful for teams focused on short-term releases, whereas larger ranges are better suited to global planning for a company.
Date Range Documentation for Road Maps
Unlimited guest users for Ultimate (ULTIMATE)
In order to improve the efficiency of working with GitLab, we decided that guest (Guest) visitors will no longer occupy the limit of users of the Ultimate instance.
Due to the fact that there can be as many guests as possible, the number of users participating in the discussion of the development is now also unlimited. Guests can increase the level of access, but do not forget that then they will begin to occupy the limit.
It is also important to remember that in cases where the user enters an instance, but does not belong to any group or project, he is also considered a guest.
Guest Permissions Documentation
Artist lists for task boards (PREMIUM, ULTIMATE, SILVER, GOLD)
Task boards are a useful tool for managing workflows: you can follow the movement of tasks between different stages of the life cycle with the help of tag lists.
In this release, we add artist lists for task boards. This list shows the tasks assigned to a specific user, which adds new features to the use of task boards.
Now you can set up a task board for your team, and then add artist lists for its members. This will make it easy to see who is working on a team on which tasks. Such functionality can be useful both for managers who are engaged in load distribution, and for ordinary users who want to orient in the work process.
You can even add tag lists and artist lists to the same board.
Artist list documentation for task boards
Assigning milestones for subsidiary subgroups (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In this release, we add the GitLab subgroup structure for the Mylstones. Now you can assign a mailstone project or group, inherited from any parent group, for any task or merge-request.
That is, if you have a high-level group with a set of milestones, you can use the same milestones for all tasks and merge-requests in all of the child subgroups. This innovation simplifies work in organizations with a complex multi-level structure of subgroups and projects.
Moreover, you can filter by such Milestone in group task lists, which will allow you to find the necessary objects at all levels of the hierarchy.
Tasks and Merger Requests for API Subgroups (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Requests for tasks and merge-requests in the API are now consistent with the web interface. That is, when you request a specific group through the API for tasks and merge-requests, you will receive the results from all the subsidiary projects or subgroups of this group. The algorithm works by analogy with viewing the same objects in the lists of groups in the web interface, which we presented several releases earlier.
Deployment tokens for Auto DevOps in Kubernetes (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Previously, when using Auto DevOps in private or internal projects, after the deployment was completed, Kubernetes did not have access to the registry. This did not allow the cluster to perform repeated image fetch operations (for scalability, work with failures, etc.)
With GitLab 11.0, a new deployment token is created. It provides constant access to the register when Auto DevOps is enabled on private / internal projects. This ensures that the cluster can perform the necessary operations, and reduces the likelihood of failures.
Deployment Token Documentation for Auto DevOps
Defining a deployment strategy in the Auto DevOps settings (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
For some applications, it is advantageous to send each change to production immediately after its readiness. For others, it may be better to collect these changes in the general environment for more thorough testing. Previously, setting up a deployment strategy for each project was possible only with the help of special variables that were configured and used for each project separately.
Starting with GitLab 11.0, Auto DevOps allows you to customize your deployment strategy with a single click. When you connect Auto DevOps for your project, you can determine whether to deploy your project automatically to production immediately, or you must first automatically deploy it to the test environment and then manually to production. The ability to configure this in one click will allow you less time to deal with deployment settings and more - to code.
Deployment Configuration Documentation with Auto DevOps
Variables for defining deployment policies for canary environments (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Often we would like to roll out changes to a small part of users or servers in order to assess the impact of these changes before deployment to the whole environment. Previously, Auto DevOps users had to make an explicit Auto DevOps pattern specialization and define the desired behavior in order to launch a canary deployment.
Starting with GitLab 11.0, users will be able to define their policy regarding canary deployment using the environment variable CANARY_ENABLED- quickly and without additional settings of the Auto DevOps template.
Deployment Policy Documentation for Canary Environments
Confirmations are always on (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Confirmations of Merge Requests - a long-standing feature of GitLab, which forces teams to review code (or whatever) in Merge-Requests. Until the confirmation is received, the merge request will be blocked for merge.
Prior to this release, confirmation was necessary to include in the project settings. In order to simplify and optimize this feature, confirmations will now be included for all GitLab projects (for Starter, Bronze and above plans) by default.
At the same time, of course, we do not want to slow down the process of creating and merge code. Therefore, when a user creates a project, the number of necessary confirmations of a merge request for this project will be reset to zero (as if the confirmations were turned off). As the project grows, the user and his team will be able to implement confirmations when the workflow requires. To do this, you will only need to change the number of confirmations to the one that will satisfy the needs of the team.
Merchant Requests Documentation
Loading cluster parameters from GKE (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Creating Kubernetes clusters in GitLab is now easier than ever. In GitLab 11.0, the values of the “project” and “zones” fields are automatically loaded from your Google account, Kubernetes Engine (GKE) and are displayed as a list for simplicity. Previously, to create a cluster when using GKE, you had to enter all this data manually.
The simplified cluster creation process allows you to quickly raise clusters from GitLab and speed up the deployment of your applications.
Documentation for adding and creating a new GKE cluster in GitLab
Disabling Auto DevOps Stages Using Variables (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When one or more Auto DevOps steps (unit testing, code quality checking, etc.) are not needed in your application, it would be great to set up the pipeline so that it runs only on the steps that you need.
GitLab 11.0 version allows you to skip one or more steps of Auto DevOps using environment variables. This will allow you to take advantage of Auto DevOps even when not all of its steps are suitable for your needs.
Environment Documentation for Auto DevOps
LFS files are included in the project import (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Git LFS helps versioning large files with Git by storing them outside of the repository and lazy downloading them as needed - instead of cloning.
When importing a project from GitHub, Bitbucket Cloud, or using a Git URL, GitLab now also imports LFS objects. Due to this, you get a complete copy of the repository, including those very LFS objects. Previously, LFS objects were not included in the import.
Operations tab (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 11.0, we added the Operations section to the navigation bar — these features are now easier and faster to find. In this release, Environments and Kubernetes have moved from CI / CD to Operations . In future releases, we will add several more sections there, for example, metrics and logs.
SAST for .NET and Scala (ULTIMATE, GOLD)
We continue to make our security tools for the most common languages and frameworks more accessible; As part of this process, we continuously extend the capabilities of the Static Application Security Testing System (SAST).
In GitLab 11.0, we added support for two new languages: .NET and Scala. If you already use Auto DevOps or the latest version of the job definition sastin your file .gitlab-ci.yml, you do not need to change anything in your projects.
GitLab Helm Cloud Chart now in Beta (CORE, STARTER, PREMIUM, ULTIMATE)
We are pleased to present you a beta version of the GitLab Helm cloud diagram . This diagram is based on a more cloudy internal architecture with a container for each GitLab component and does not require a shared data warehouse. This increases the resiliency, scalability and performance of GitLab at Kubernetes.
GitLab Helm Chart Documentation
Easy deployment and integration of JupyterHub with GitLab (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
JupyterHub is a multi-user service for easy support of notebooks within the data analysis team. Jupyter notebooks offer an interactive, programmable environment that is commonly used for data analysis, simulation, visualization, and machine learning.
GitLab 11.0 can deploy JupyterHub to the Kubernetes integrated cluster with one click — it is automatically configured to use GitLab for seamless authentication. Additional features like HTTPS , filtering by groups and customizable notebooks will be added in future releases.
JupyterHub Deployment Documentation
Extended task weight values (STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
The weight of tasks in GitLab is useful for indicating the evaluation of efforts or any other metrics associated with the work on the task. Previously, you could assign task weights only from 1 to 9 - but this limited those teams that want more detailed estimates.
Starting with this release, the weight of the problem can be any non-negative integer, from 0 to infinity. You no longer have restrictions on estimates. In addition, task schedules automatically take into account new weights, and your team can immediately appreciate the benefits of the extended range.
Combining system notifications for consecutive task description updates (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab will allow active asynchronous collaboration and communication. Because of the opportunity to document ideas and discuss them in so many places, we call for the maintenance of a single source of truth in the description of the task or the epic.
This leads to the fact that the descriptions are updated frequently. Sometimes - several times in minutes. It turns out a lot of system notifications that the description has been updated. From this release, the system notes on the update descriptions will be merged into one for a short period of time. This will reduce the amount of visual noise and make comment navigation in GitLab a bit easier. In the next release, we will add similar functionality to the descriptions of the Merge-Requests.
View Kubernetes pod logs (ULTIMATE, GOLD)
Developers are critical to the ability to view logs in order to understand how the application behaves and to track possible problems. From this version, viewing the logs of the problem submission is available in one click.
On the Environments page, the statuses of the pods of each application are displayed using the deployment boards . By hovering over each of the hearths, the full name of the hearth and its status appear, and by clicking it, its logs are displayed.
Documentation of submission logs
Master role renamed to Maintainer (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In the GitLab team, we are trying to build an independent culture . Therefore, even in the GitLab product, we are looking for ways to reflect it.
We decided to rename the Master role to the Maintainer role. This will remove the negative context that could be associated with the term “Master”, and, at the same time, the term “Maintainer” is easy to understand. With each small step, we are developing both as a product and together as an industry.
Documentation of access rights
Tag list redesign (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tags are a very powerful GitLab mechanism. Teams continue to create and use more and more tags, and we are trying to make them easy to manage. In this release, we cleaned the design of the list of tags, simplified the interface, made the information more readable, and made the interface chips so that you can quickly manage the details of a particular tag.
Consistent name format for the task scope attribute of the API (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We made a small change to the scope attribute of the task API to align it with the snake case format. The 'scope' attribute now uses variable values created_by_meand assigned_to_me. Starting with GitLab 11.0, you need to use this format instead of the previous one, which used spelling through a hyphen (kebab-case).
Regular expression support for variable expressions (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 10.7, we added support for expressions with variable for keywords onlyand except. These keywords determine whether to create work when a variable exists or has a specific value.
In GitLab 11.0, we extended this syntax: regular expressions are now available. You can create flexible definitions based on a variety of parameters. For example, skip work with a specific commit message.
Regular Expression Support Documentation for Variable Expressions
Getting the IP address of GitLab Runner via API (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 10.6 we added the mapping of the IP address of a particular GitLab Runner in the details of the web interface. This is very useful for getting information about the infrastructure, managing it, and tracking problems.
With GitLab 11.0, we also issue this information on an API request, so now it can be used in automated processes.
For this feature, thanks to Lars Greiss .
GitLab Runner API Documentation
GitLab Runner 11.0 (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Also with this release we release GitLab Runner version 11.0. GitLab Runner is an open source project used to run CI / CD and send the results back to GitLab.
Key changes to this release:
Добавлили опцию --pausedin commandgitlab-runner register- Changed the names of Prometheus metrics
- Began to rename the setting "metrics server" to "listen address"
- Renamed CI_COMMIT_REF to CI_COMMIT_SHA
You will find a complete list of changes in the CHANGELOG file of the GitLab Runner .
Improved tracking of outdated settings (CORE, STARTER, PREMIUM, ULTIMATE)
Starting with GitLab 11.0, the Omnibus GitLab package will check gitlab.rbfor outdated settings before starting the update. In case the outdated settings show up, the package will cancel the update process before making any changes. This will allow existing versions to continue to work correctly until the administrator updates the problematic settings.
Project level pipeline ID (CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
When you run CI / CD for your project, sometimes you need a way to distinguish one run from another. For this purpose, a unique identifier is useful, which changes each time a new pipeline is created. Such an identifier has already been - an environment variable was used for this CI_PIPELINE_ID. But this counter was one for the entire GitLab instance, which is why it grew too quickly, threatening problems with long numbers.
In GitLab 11.0, we present another environment variable: CI_PIPELINE_IID. It contains a reference to which project it belongs to. This means that such a counter will increase only when a new launch is created in a particular project. Numbers will not grow as fast as in the case of the previous counter, and developers will be able to use this variable during the release process - for example, as part of the version number.
Documentation on predefined CI / CD variables
Detailed release notes and instructions for updating / installing can be found in the original English post: GitLab 11.0 released with Auto DevOps and License Management .