GitLab 10.2 released: Customizable task boards and GitLab Geo in shared access

In this release, we have added opportunities to improve planning, deployment, reliability, and more.

Improving the efficiency of your work planning

In my opinion, the tasks of GitLab have a lot in common with water: they are necessary for life, but you can drown in large numbers.

In teamwork with a general overview, it is useful to narrow it down only to tasks that are important in a particular context. Previously, GitLab allowed the use of filters to display tasks associated with a specific milestone or task board label, however, this was only a temporary solution. Perhaps you had to save to bookmarks and send colleagues links to task boards ..

In this release, we introduce a task board setting with which you can save a sample by milestones, labels, weight and task performers, which will allow each team member to see the same tasks.

Accelerated fetch

Development teams are increasingly distributed geographically ... This is one of the reasons why Git is so popular: it is distributed by nature - your local repository contains copies of each commit, file and branch in the project history. Downloadable history dramatically speeds up the development process.

However, if there is only one physical instance of the repository, it is possible that it is located far from distributed commands. This slows down the loading of a large number of small files. We are pleased to announce that GitLab Geo has been released to the public in this release. GitLab Geo allows you to run read-only GitLab replicas (including its interface) in physical proximity to remote commands.

Fault tolerance and scalability

Due to the fact that GitLab is designed as one application, it contains a single data repository for source code repository, task tracking, CI / CD and monitoring. Such a unified approach contributes to visibility, increased efficiency and simplified work with the project for all participants.

GitLab is the core of development for many teams, so it should work flawlessly regardless of the time of day. In this release, we are proud to announce that PostgreSQL High Availability is being shared , making it easy to set up and run a Postgres cluster for GitLab. A simple installation process based on Omnibus and an automatic fault tolerance system will allow your developers not to be distracted by extraneous problems.

The bottom line:

• Single source of truth == :)
• Single point of failure == :(

Accelerated deployment on Kubernetes

We strive to improve the work with GitLab Kubernetes in each release. Last month, we simplified the creation of Kubernetes clusters. But after all, after creating the cluster, you need to configure additional services, for example, an external access controller (external access controller). You no longer need to spend time on it: in this release we added installers in one click for Tiller and Ingress . And next month we plan to add support for the simultaneous deployment of several clusters at once. We strive to ensure that each of the monthly updates is a complete and valuable product.

Do not miss the new features.

This month we have added a lot of interesting new features, for example, limiting the authorship of commits and raising project milestones to group milestones .

Further in the article we will dwell on these and other innovations of GitLab 10.2.

We invite to our meetings!

MVP of the month - Travis Miller

Over the past few releases, Travis has been working on improving GitLab Pages, and in GitLab 10.2 he contributed to the creation of a new Pages interface to manage existing domains. This innovation allows you to program key tasks, such as updating a certificate or transferring an existing domain to HTTPS.

We thank Travis for his contribution! As a sign of gratitude, we sent him socks, stickers, a T-shirt and a glass of GitLab, which seemed to be to his liking.

Customizable task boards (EES, EEP)

Many teams use a common task board to plan and track workflow. Each team member should see the same set of tasks on it. Previously, only Mylston could be tied to the task board, and now Milestone (including the “No Milestones” option), tags, artist and weight, which expands your team’s capabilities.

This configuration is saved along with the board, so that any user who views it will see all of these filters. You can customize and edit the board configuration by clicking the View scope button or the Edit board button, depending on your access level .

Documentation on setting up task boards .

One-click installation of Helm and Ingress on Kubernetes (CE, EES, EEP)

In GitLab 10.1, you can now connect your Google Account to projects and create a new Kubernetes cluster directly from the GitLab Cluster page. In the future, this cluster can be used to deploy applications for review and development environments.

In GitLab 10.2, we continued to work in this direction, adding the ability to install Helm Tiller and Nginx Ingress for your GKE cluster in one click, which further reduces the time spent on developing applications.

Documentation for installing applications on GKE clusters .

Limit Authorship Commitments (EEP)

GitLab Enterprise Edition Premium provides additional workflow management and development environment controls.

In version 10.2, it became possible to configure push rules in such a way that only the same user can be the author of a commit, which push changes to the repository. This will prevent unauthorized code from entering your project, as well as increase the level of control over the development process.

This option can be enabled for individual repositories, as well as for the entire GitLab instance, which will allow you to control the workflow on the entire server.

This innovation, combined with the ability to reject unsigned commits in the EEP , provides full control over the identification and verification of the changes made.

Documentation on the rules of push .

GitLab Geo is now shared (EEP)

Many teams using GitLab are distributed in different geographic locations, but their GitLab instance is in one place. GitLab Geo eliminates the complications associated with this by speeding up fetch operations, such as cloning repositories.

Now GitLab Geo is shared! After setting up GitLab Geo supports synchronization of secondary read-only GitLab instances with the main one. GitLab Geo can be used to access Git, LFS objects, tasks, wikis and CI artifacts of the nearest GitLab instance.

Please note that although Geo and High Availability are now publicly available, using them simultaneously is considered beta .

Important changes in GitLab 10.2:

• Added GEO replication support using HTTPS
• Added PostgreSQL secure replication
• Added API to get Geo status
• Improved replication error handling

The full list of Geo changes in version 10.2 can be found here .

GitLab Geo Documentation

Postgres HA is now shared (EEP)

GitLab is one of the key development tools for many organizations: it supports the code repository, CI / CD, task management and much more. In order to be confident in the continuous operation of GitLab, you can deploy it in a high availability configuration .

We are pleased to announce that, starting with GitLab 10.2, PostgreSQL High Availability is publicly available. The Omnibus installation package is included in GitLab Enterprise Edition Premium, which makes it much easier to create and configure Postgres database clusters .

In the event of a database node failure, the cluster will automatically switch to the secondary one, which guarantees the continuity of the development process.

Database configuration documentation for GitLab HA .

Canary Deployment Performance Assessment (EEP)

In GitLab 9.1, we added canary deployments to GitLab CI, which increased the level of control over the launch process for new releases. The essence of this approach is that before a global launch, the deployment of a new version of the product is carried out only on a small percentage of nodes, so that changes affect a small proportion of users, and in case of unforeseen complications, these changes can be easily corrected or rolled back.

In GitLab 10.2, we add the ability to track the system metrics of such “canary” versions, making it easy to compare the actual performance of different versions. Now, developers can quickly assess the impact of changes on performance and decide whether to perform a full-scale deployment. And the best part is that all this can be done without leaving GitLab!

Documentation on the evaluation of the performance of canary deployment .

Improved Event Revision (EES, EEP)

Auditing events in GitLab Enterprise Edition helps strengthen control and improve reporting. In GitLab Enterprise Edition Starter (EES), you can view a revision of events in each project or group. GitLab Enterprise Edition Premium (EEP) includes a centralized log in which all project events are concentrated in one place.

GitLab 10.2 EES and EEP now include additional events for actions on projects or groups. For example:

• Creating a project or group
• Deleting a project or group
• Move, rename, or assign a new owner for a project
• Change group visibility
• Add user to group (with user access rights displayed)
• Change user access rights
• Adding a project to a group or removing it from a group

In GitLab EEP, the revision data of a remote project or group is now stored on the server in a common log and available to the administrator. Also now includes the IP address of the user performing the action.

Documentation for improved event auditing .

Subgroups and projects on the groups page (CE, EES, EEP)

Subgroups are a great way to organize projects or teams in GitLab. With almost unlimited inheritance of groups, you can create a structure to display complex repositories, microservices, or even outline the internal structure of your development teams.

We have overhauled the pages of the GitLab groups. It has become more convenient to move around and look for subgroups and projects. Now on the groups page you will see the navigation in the form of an expanding tree that will help you quickly find what you are looking for or discover new projects and groups.

Documentation of subgroups and projects on the groups page .

Epic (EEU)

In this release, we launch the very first version of Epics (Epics) as the first part of the Portfolio Management . Epics are made to allow you to plan and control your work at the level of features, rather than the design and details of the task.

The epics are aimed at working at the group level. After creating an epic with a name and (optionally) a description, you can create many tasks and link them to an epic. This is a typical top-down process where you first plan a feature at the top level, and then break it up into smaller tasks to make it easier to implement. And vice versa: you can apply a bottom-up approach when taking several existing tasks and combining them into one new epic.

Each task included in the epic group or any of its subgroups can be linked to this epic. Epic also has additional options.
the planned start date ( planned start date ) and the planned end date ( planned end date ).

Epics are included in the Enterprise Edition Ultimate (EEU) and GitLab.com Gold Subscription Plan .

Epic documentation .

Private access tokens will replace private access tokens (CE, EES, EEP)

For each personal access token, you can select only the necessary API privileges. This makes accessing GitLab through an API or through third-party applications more secure.

Private tokens were previously banned; now they were completely removed.

After the upgrade, all private tokens will become personal access tokens, so all existing applications will continue to work as before.

Documentation of personal access tokens, replacing private tokens .

Rise of project milestones to group Milestown (CE, EES, EEP)

When you have outgrown your project, you can easily upgrade the project's milestones to the group's milestone. Just go to the Milestone page of the desired project and click the button to make it a Milestone group. As with the tags, all the project Milestone with the same name for all the projects of the group will be united into one Milestone group. And all the tasks and merge requisitions, previously associated with one of the united Milestone, will become attached to the resulting Milestone group. Project task boards associated with the previous project milestone will now be associated with the group Milestone.

Documentation about raising project milestones to group wrestlers .

Limiting Mirroring Push to the Repository (EES, EEP)

Push mirroring works like this: the repository sends all incoming changes to another, predefined, repository.

Administrators can now restrict access to mirroring pushes so that it is available only to administrators. This will help prevent automatic mirroring of private projects to another repository, which may be external or unsafe.

Documentation for mirroring repositories .

Restored the ability to select a readme project overview (CE, EES, EEP)

The settings of the “preferred project home page” allow you to select the content that you will see on the home page of any open project. You can select project activities, file list and readme, or just readme.

In GitLab 9.0, the ability to select only the readme has been removed. Now this opportunity has been returned for those who prefer a minimal project review.

Documentation on the project readme-review .

Improved localization (CE, EES, EEP)

We continue to translate GitLab into different languages. This time, we 'externalized the lines in the “Contributors” and “Tag” pages, allowing our translation community to add new languages ​​and lines to GitLab.

If you want to participate in the localization of GitLab, we invite you to join our translation community .

Documentation on localization improvements .

API for GitLab Pages (CE, EES, EEP)

GitLab Pages allows you to publish a static site directly from your project pipeline. If you want to make it more professional, you can set up your own domains for your content and protect them with certificates.

In GitLab 10.2, it became possible to manage your own domains for GitLab Pages through API requests. You can automate the connection of new domains and information from existing ones, as well as update domain data - for example, when the SSL certificate was updated.

API documentation for GitLab Pages .

Project visibility as a CI / CD variable (CE, EES, EEP)

In GitLab, you can determine which project — public or private — you want to create. When working with a pipeline, you sometimes need this information to perform various actions.

In GitLab 10.2, this information is in the CI_PROJECT_VISIBILITY variable. Using it, you can determine, for example, whether public access to artifacts or Docker images is allowed.
It is very convenient when you have a shared template that is used for different projects.

Documentation of the variable for visibility of the project .

Omnibus Improvements (CE, EES, EEP)

• When deprecated configuration settings are used, warnings are now clearer.
• Added support for running separate Redis instances for each persistence class.
• Updated OpenSSL to 1.0.2m.
• Updated libxml2 to 2.9.6.

Documentation on Omnibus improvements .

GitLab Mattermost 4.3.2 (CE, EES, EEP)

GitLab 10.2 includes the Mattermost 4.3.2 ,
An open source alternative to Slack . The new release includes support for tablets in beta, improvements to the mobile application, and more. In this version there are security updates , we recommend upgrading .

Documentation for GitLab Mattermost 4.3.2 .

GitLab Runner 10.2 (CE, EES, EEP)

This version also released GitLab Runner 10.2. This is an open source project that allows you to run CI / CD works and send the results back to GitLab.

The most important changes are:

• The minio library has been improved : it now supports Amazon S3 accelerated endpoints (Amazon S3 Accelerated endpoints) and the eu-west-2
  
  • helper_image option added to docker executor helper_image

For a complete list of changes, visit CHANGELOG GitLab Runner .

GitLab Runner Documentation 10.2 .

Performance Improvements (CE, EES, EEP)

Performance is an important part of GitLab, allowing it to scale to hundreds of thousands of users.

GitLab 10.2 has a new GitHub importer that uses Sidekiq to perform tasks in parallel, which significantly reduces the time required to import projects from GitHub. If a limit is reached on the number of requests to GitHub, the new importer will suspend work and continue it when the limit is reset. However, none of the Sidekiq handlers will stop working.

For small projects like https://github.com/yorickpeterse/oga , the import time decreased from 5 minutes to 30-60 seconds, and for such large projects as https://github.com/kubernetes/kubernetes , the import time instead of several weeks turned into 6.5 hours.

More information about the new GitHub importer can be found in the CE request .

In addition, GitLab 10.2 includes 12 more performance improvements focused on speeding up download requests. In addition, we accelerated the loading of tasks, as well as reduced the number of some extreme cases that significantly consume server resources.

A complete list of performance improvements in GitLab 10.2 .

—-
Detailed release notes and upgrade / installation instructions can be found in the original English post: GitLab 10.2 released with Configurable Geo General Availability .

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