GitLab 9.1 Released: Service Desk, Burndown Charts and Canary Deployments

GitLab is designed to give you constructive feedback at all stages of the application life cycle and in different time frames.

In the version of GitLab 9.1 appeared canary deployment . They allow you to deploy new code on a small part of your infrastructure. If problems are found, they will have time to affect only a small part of users, and you can easily roll back to the previous version. This is a quick feedback from the combat environment .

With the new feature of Service Desk, your users can send their questions and report problems to a special email address, separate for each project. According to the letter from the user, Service Desk gets a confidential problem (issue) in your project. When someone comments on a task, the user receives this comment in a reply letter. This is a user feedback channel built directly into GitLab.

GitLab 9.1 also features task execution charts (burndown charts) . They give feedback on the work of the team . Now you can see how work is going on tasks related to a specific Milestone and correct the development process in a timely manner.

The Heroku blog recently published an article stating that the GitLab CI continuous integration server (embedded in GitLab itself) outperformed its competitor Travis CI in terms of issues on Stack Overflow. Google Trends shows a similar result in the popularity of search queries. And finally, all over the world, GitLab is used as a self-hosted service for working with git in two of three cases. Thank you all for your support!

( MVP ) of this month - Maxim Rydkin

This month’s MVP is Maxim Rydkin . He developed a setting that allows you to automatically cancel waiting for the launch of the conveyors waiting for execution, if they are no longer relevant. This is very useful when you push another commit on GitLab, and immediately want to start a small edit. At the same time, the pipeline waiting for processing on the first commit will be canceled, extra time and resources for its processing will not be spent, and you will quickly get the result of the pipeline execution on the second commit. Thank you, Maxim!

Service Desk (EEP)

Service Desk is a powerful new feature that allows your team to communicate with users via email directly from the GitLab interface. For her work does not need any additional tools. This feature will help you not to lose feedback from users and work on those features that solve the real problems of these users.

Your users can send bug reports, feature requests, or any other feedback via email directly to your GitLab project. Each correspondence will become a new issue. Your team members, in turn, will be able to respond to emails simply by commenting on the task in GitLab.

Since the Service Desk functionality is built directly into GitLab, you do not have to waste time setting up integration with external services and switching between different tools when working with each request. This will help you respond faster to requests from users and develop the necessary updates.

Just enable the feature in the project settings. A unique mailing address for this project will be created automatically. Each time a user sends an email to this address, GitLab will create a new confidential task in the corresponding project. Comments left by members of your team will be sent to the user in a reply email. The user can also reply to such a letter. In this case, all correspondence will be displayed in the comments to this task.

Tip: when you implement the feature requested by the user or fix a bug, write about it in another comment.

For more on Service Desk , see the documentation.

Canary Deployment (EEP)

A company that implements continuous delivery of delivery should choose a specific deployment strategy. One of the most popular strategies is canary deployment. Their meaning is that the new version is first deployed on a small part of your infrastructure. And then canaries? Once, canaries were taken to coal mines to determine the level of methane: when it rises, the canary dies. Similarly, if the new version of the application behaves strangely, then it will affect only a small proportion of users, and you can easily correct or roll back the changes.

In GitLab 9.1, the strategy of canary deployments in Kubernetes is immediately available out of the box. Projects using Auto Deploy can switch to an updated Auto Deploy template, in which this feature is already implemented.

If you are writing scripts for the deployment pipeline or you want to know more about this feature, then the documentation on how to add a stage (canary) of a canary deployment will help you.

As the pipeline proceeds, Deploy Boards will explicitly mark portions of the infrastructure used for the canary deployment.

This will help you quickly obtain information about the state of each environment and the overall deployment.

Burndown Charts (EE)

We consider GitLab as an increasingly useful tool for recording and managing the development process. In this release, we added schedules for performing tasks in your projects. They will show you how many tasks are completed every day on the way to the next mailstone. You can see how many tasks are left and what is the total weight of open tasks. The dynamics of changes in this share will tell you how you meet deadlines and help you make the necessary decisions in advance.

In your project, every mailstone for which start and end dates are set automatically gets its schedule for completing tasks. This graph is on the page Milestone. You can switch it to display the total weight of open tasks on a specific date. To make this feature work correctly, assign tasks an adequate weight. An open problem with zero weight does not increase the total weight of all open tasks.

Adding a chart, we took a chance and redid the whole page. Now it has become easier and more convenient, in the spirit of the interface of the remaining pages of GitLab.

Our documentation will tell you more about task schedules .

Tag Protection (CE, EE)

In some git models, not everyone should have the right to create and update tags (tags). GitLab 9.1 has the ability to protect tags in order to limit the ability to create or modify tags.

Tag protection is very similar to branch protection . You can use this feature in any of your projects. You can limit the list of those who can create tags, as well as customize the mask (wildcard), which must correspond to the names of the tags.

All information about tag protection is in the documentation.

Recent Searches (CE, EE)

We’ve added a handy drop-down list to the search bar to show your recent searches. Data is stored in your browser, the feature does not require any configuration.

For more information on how search history works, refer to the documentation.

Discussions in Merge Requests and Tasks (CE, EE)

In GitLab, you can start a discussion by commenting on a line of code in a merge-request diff-e. The discussion is “solvable”: when it comes to some result, it can be noted as solved, like a small task. Starting with version 9.1 of the discussion, it is not necessary to bind to a line of code — you can start them directly in the main comment stream.

This is very convenient when you want to discuss the contents of the entire Merge-Requester, but at the same time use the tools to resolve the discussions.

In this release, we also applied this principle to comments in problems.

The meaning of the discussion of the problem is in the free exchange of ideas. Therefore, we decided to add discussions to the tasks, but not to include the possibility to mark them as solved.

This will make it even more convenient to use GitLab for collaboration, but it will not disrupt the process of discussing new ideas.

Since commits and snippets can also be discussed, a new feature has appeared in them.

For more information about merge-requesting discussions and tasks, see the documentation.

Solved discussions in Merge Requests

Discussions in the tasks

Resolution of Merge Requests when creating a new task (CE, EE)

Previously, it was possible to resolve all discussions of a merge request by creating a new task, so that these discussions were not lost, but transferred to a new task.

In this release, we expand the flexibility of this functionality: now you can choose one specific discussion to resolve and transfer to a new task, which will allow you to postpone some of the problems for later and focus on solving problems that are important for this merging request.

More information on resolving discussions in merge requests by creating a new task can be found in our documentation .

Integration with Microsoft Teams (CE, EE)

We want GitLab to be as complete a tool as possible, helping as quickly as possible to go from idea to release. This requires integration with the platforms on which ideas are formed and their discussion takes place, such as the Mattermost, Slack, or the newly emerging Microsoft Teams.

The first step in integrating with Microsoft Teams was the ability to add alerts for GitLab events to the Microsoft Teams room using Office 365 Connectors .

This means that you can now receive alerts in Teams when you push to the repository, create or update tasks or Merge-Requests. You can also transfer to Teams the results of the continuous integration pipelines (CI pipelines).

Alerts are displayed as a card with all the details of the action and related links to GitLab pages with more complete information.

More information about integration with Microsoft Teams in our documentation .

Simplify work with file templates (CE, EE)

GitLab has long been able to create file templates. For example, you can use the .gitlab-ci.yml file template to configure continuous integration. Using GitLab 9.1 makes it even easier to use templates.

Now when creating or editing a file, GitLab lists all types of templates, as shown in the screenshot below. Changing a file template completely replaces its contents in the editor, however, this action can always be undone without loss of information.

Automatic update of task names (CE, EE)

When using GitLab by a large number of users, data is constantly updated. Starting with this release, task names are updated automatically, without the need to refresh the page.

This type of functionality suggests itself for many elements of the task page, and indeed for the whole GitLab as a whole. We plan to do this in future releases.

Application Monitoring Improvements (CE, EE)

A set of small changes has been made to the application monitoring process, improving its functioning and simplifying work with it. For example, a beautiful startup screen, performance graphs, and additional debugging information appeared.

Other GitLab 9.1 improvements

Simplify Merge Requests (EE) Approval Settings

The approval functionality allows you to create a list of users or groups for a merge request and block it until a certain number of people from this list confirm it. This approach is an important part of the code review process in many organizations. This release simplifies the project settings interface, which lays the foundation for further expansion of its capabilities.

More information about the approval of merge-requests in our documentation .

Disaster Recovery Improvements (alpha) (EEP)

GitLab 9.1 includes improvements in disaster recovery functionality, the alpha version of which we released with GitLab 9.0 .

First, we simplified the process of working with Geo . Secondly, we reduced the number of actions required to configure Geo .

And thirdly, we added support for replication of the following types of files stored on the disk: task, merge-request, attachments to comments, as well as avatars of users, groups and projects. In future releases, we plan to continue active work on improving disaster recovery .

More information about the alpha version of disaster recovery in our documentation .

Adding mini pipelines to the commit view tab (CE, EE)

Now mini pipelines are displayed in the system information window of the commit view tab. Previously, they were only available when viewing Merge-Requests.

More information about conveyors in our documentation .

Notifications about the success of the pipeline are disabled by default (CE, EE)

In order to reduce the flow of redundant information, as well as to give users more control over the alerts, we changed the way conveyor alerts work in GitLab 9.1. Now notifications about the success of the pipeline are disabled by default. To connect them, you need to change the alert level to Custom and select the Successful pipeline . It is also worth mentioning that with this approach, only the user who starts the pipeline will receive a letter.

More information about conveyor alerts in our documentation .

System Notes Icons (CE, EE)

As new functionality is added to GitLab, there is a growing need for a chronological display of information about the changes made, which are in discussions of tasks and merge requests.

In this release, next to the system notes icons are added, thanks to which you can easily distinguish system actions from user comments, as well as evaluate the development process of an object, simply by looking at discussing it.

Usage statistics (CE, EE)

GitLab Community Edition adds usage statistics functionality, previously available in GitLab Enterprise Edition from version 8.10 .

With its help, in the coming months you will be able to evaluate the activity of the users of your instance relative to all other GitLab users. More information in the relevant task , as well as in the task from which it came . Statistics is sent weekly, you can see the exact numbers in admin > cohorts . You can refuse to participate in the collection of statistics through admin > settings .

More information about collecting statistics in our documentation .

Focus Mode for Task Boards (EE)

Task Boards (Issue Boards) - an excellent tool for planning and managing tasks, which are engaged in the development team. With it, you can track the movement of tasks between different stages of development.

In this release, focus mode is introduced for task boards (focus mode), which hides the navigation interface.

This mode can be useful in cases where many people look at one screen while working together. That is, first of all, it is intended for teams that are physically located in one place. Click the button in the upper right corner of the taskbar window to turn it on / off.

More information about task boards in our documentation .

Docker Multiple Image Projects (CE, EE)

In some situations, developers can create multiple containers based on the same code base. This can occur when creating a container at an early stage with a bookmark for its use at a later stage; or when packing different versions of dependencies.

In GitLab 9.1, the container registry supports multiple image names for each project, providing an easy way to store multiple project containers.

For example, it now supports storing registry.example.com/group/project/core:latest and
registry.example.com/group/project/dependencies:latest .

Thanks to André Guedes for his fantastic contributions!

Learn more about the container registry in our documentation.

Automatic cancellation of excess conveyors (CE, EE)

When you have a large number of commits in a short period of time, several pipelines on commits of one branch can queue up. Previously, pipelines were processed primarily on the principle of “first come, first processed”, and because of this, the pipelines were first of all launched for old commits, even if they were already replaced. This caused delays in understanding whether the current branch was being tested, plus it became inefficient using CI runners.

With the release of GitLab 9.1, pipelines for old commits (namely, non-HEAD commits)
can be automatically canceled when a new pipeline starts for the same branch. This will help to process the queue more efficiently and reduce the easy-to-run new main (HEAD) pipeline.

Conveyors in “wait only” mode that have not yet started will be automatically canceled. Any pipeline launched before the arrival of the new push will continue to work until it is executed normally.

If you want to add this functionality, enable it in the settings of the CI / CD Pipelines project. In future releases, auto-cancel will be enabled automatically.

Details on the automatic cancellation of unnecessary pipelines can be found in our documentation.

Triggers of pipelines on schedule (CE, EE)

With the release of GitLab 9.1, we added alpha support for scheduling a pipeline for its periodic launch. A daily pipeline, for example, can be run to test external dependencies or for nightly testing. To configure a planned pipeline, add a Pipeline Trigger , edit it, and enable the Schedule Trigger. Use cron format to set the schedule.

Read about pipeline triggers on schedule in our documentation.

Improved support for tasks with large logs (CE, EE)

Focusing on improving performance, we optimized the processing of large task logs. GitLab 9.1 now only displays the last 500 Kbytes of log when viewing a job, which significantly reduces the page response time, as well as its throughput.

Since errors in the task with continuous integration (CI) constantly arise closer to its end, it is often not necessary to send and display the entire log. This is especially important for large projects like Android, where the job log alone can occupy 60 MB. If further analysis is required, you can always download the entire log by clicking on the Download button.

Advanced Auto Deployment (CE, EE)

Together with support for canary deployments, we made two other important changes to automatic deployment (Auto Deploy) . First, we added alpha support for applications requiring the use of a database, by automatically providing PostgreSQL by default. You can use variables to set permissions and change the database name, or you can disable Postgres by checking yes in the DISABLE_POSTGRES variable. We also added support for private projects as an experiment, which will allow Kubernetes to authenticate and download the application container from the GitLab Container Registry.

Details of private projects and support for PostgreSQL database of automatic deployment, as well as the important limitations - in our documentation.

The list of pipelines is now updated automatically (CE, EE)

One of our obligations is to constantly make sure that when using GitLab, users get the best possible experience. To do this, we changed the overview page of the pipelines: now it is updated automatically. In future releases, we will continue to work on additional workflow models, which will eliminate the constant need to be updated manually.

Learn more about conveyors in our documentation.

Elasticsearch (EE) enhancements

GitLab 9.1 EE is an experimental repository indexer . It is completely rewritten, so it became 4 times faster. To enable it, simply tick the admin panel:

Send us feedback - after several releases we want to make this indexer default. Additionally, administrators and validators can now use global search when Elasticsearch is enabled, and the search results are highlighted again.

More information about Elasticsearch in our documentation.

GitLab Runner 9.1 Changes (CE, EE)

Also along with the latest version of GitLab we released GitLab Runner 9.1.

The most interesting changes

• Expanded verify command with runner switch ( merge request )
• Added log_level ( merge-request ) option in config.toml
• Fixed container cache detection regression ( merge request )
• Added cleaning and renaming provider of docker metrics ( merge-request )
• Added histogram metrics for docker creation time ( merge-request )

You can find a list of all the changes in the CHANGELOG GitLab Runner.

Learn more about GitLab Runners in our documentation.

Performance Improvements (CE, EE)

For us, the main priority is always the acceleration of GitLab. Every month we improve performance to make GitLab faster and more reliable. This applies not only to GitLab CE and EE - GitLab.com increases the speed and reliability of operation for all users.

In GitLab version 9.1, we almost halved the time required to view the list of projects and merzh-requests , improved analytics availability of the input , made faster and more reliable import of GitHub projects, and took several big steps towards updating GitLab with no time delays .

Take a look at the complete list of GitLab 9.1 performance improvements. In addition, we already have a huge number of tasks related to performance improvement, which are planned in version 9.2 .

Learn more about monitoring GitLab performance in our documentation.

Omnibus Improvements (CE, EE)

SUSE Linux Enterprise Server 12.

GitLab is now available on SUSE Linux Enterprise Server 12.2.
Read the installation instructions .

GitLab Mattermost 3.7.3

GitLab 9.1 includes the Mattermost 3.7.3 , an open source alternative to Slack, providing messaging on the web, PC and mobile phone with the ability to archive and search for messages. This month’s enhancements take into account the next generation of beta versions of iOS and Android applications, integration into the new command line interface and much more.
This version contains security updates , so we recommend upgrading .

Mattermost 3.7.3 appeared already in version GitLab 9.0.4. Anyone using GitLab 9.0.4 or later should have received a patch.

Other improvements

• GitLab now comes with Git 2.11 ( ticket ).
• Now you can use the Terraform setting to launch the GitLab instance on the Google Compute Engine (GCE) ( ticket ). The development of gitlab-runner launch support is underway at
  ( ticket )
• Google Cloud Storage can now be used as a backend for the Container Registry ( ticket ).

Learn more about Omnibus GitLab in our documentation.

Termination of support

Ubuntu package 12.04

GitLab 9.1 is the latest release to support Ubuntu 12.04 packages, since April 28, Ubuntu 12.04 has ceased to exist. GitLab 9.2 will still be available on Ubuntu 14.04 and 16.04 versions.

Until May 22, 2017.

OpenSUSE 13.2

GitLab 9.1 will also be the latest release to support openSUSE 13.2 packages, as they reached the end of their lives (EoL) earlier this year . GitLab 9.2 will be available for openSUSE 42.1.

Detailed release notes and instructions for updating / installing can be found in the original English post: https://about.gitlab.com/2017/04/22/gitlab-9-1-released/

Translation from English is made by translational artel "Nadmozg and partners", http://nadmosq.ru . Worked on the translation nick_volynkin , rishavant and sgnl_05 .