GitLab 9.0 Released: Subgroups and Deploy Boards

We recently released GitLab 9.0 , 18 months after the release of version 8.0 . During this time we have made many significant changes in GitLab , releasing a new version on the 22nd of each month. Let's briefly summarize the results to which we came from release 8.0, and see how the old features relate to the new ones from version 9. Or you can go to the features that appeared in 9.0.

From idea to production

With its latest releases, GitLab has changed the team's approach to product development. In just a few minutes you can deploy GitLab in the container scheduler (container scheduler), add CI / CD with automatically deployed review apps, use ChatOps and analyze your cycle time. In version 9.0, you can view your deploy boards on deploy boards and track application performance with Prometheus. Based on our Master Plan , GitLab 9.0 provides a huge set of DevOps tools for developers. Let's see how it works.

Usability and design

In version 8.0 , we refreshed the GitLab interface by changing almost every element of the UI and greatly improving usability (we even updated the logo a few months ago.) Since then, we continue to invest in design, building up our team of UX designers and researchers who have been working hard on improving usability, find and treat the main pain points in all areas from small CSS tweaks to changes in the main streams of UX. In each 8.x release, we gradually developed the design. And in GitLab 9.0 we have achieved significant success in simplifying our common, group and project navigation . This is a key change that makes the GitLab feature set more powerful.

In order to continue improving UX, we have a research group , in which you can influence the future of GitLab. By joining this group, you will be the first to try out new features, and we will consider your thoughts about them in product improvements.

Join our research team .

Digital Work Together

GitLab helps you come together for digital collaboration. We have made a lot of changes in the issues (issues), based on the collaboration in GitLab. For example, task weights ( 8.3 ), linking them with merge-requests ( 8.3 ), moving a task to another project ( 8.6 ), and a powerful filter and search interface ( 8.16 ). We also released issue boards ( 8.11 ), which provide a simple mechanism for managing the flow of tasks using different stages (“lists”, in GitLab). GitLab 9.0 continues to further improve the board, improving integration with the Milestone .

We are pleased to introduce subgroups to GitLab 9.0 , another big step in improving collaboration in GitLab. This new powerful group paradigm in groups helps teamwork on team-based and team-first principles even in large organizations with a large number of different departments. Our mission is to allow everyone to contribute . Version 9.0 helps simplify processes, wherever you work, so in fact, everyone in your organization can contribute to a common task.

Review and code collaboration

We continue to improve review and co-writing code in GitLab from version 8.0, including such functions as merge after successful execution of the pipeline ( 8.3 ), defa (code diffs, 8.4 , 8.5 , 8.7 , 8.10 , 8.15 ), the conflict editor ( 8.11 , 8.13 ), version of Merge-Requests ( 8.12 ), blocking of Merge until the resolution of discussions ( 8.14 ), switching permissions ( 8.16 ), as well as squash and merzh ( 8.17 ). Many of these and other features include a merge request widget. Therefore, in GitLab 9.0, we corrected its design in order to coordinate with many existing and future features that interact with it.

Continuous integration

Starting from version 8.0 , continuous integration (CI) has been added to GitLab. After that, the CI ( 8.4 ) functionality was added to the API, and pipeline events were made available via web hooks ( 8.11 ). The integration of pipelines into merge-requests ( 8.11 , 8.17 ) and commits ( 8.13 ) was also made, in addition, a graphic display of pipelines ( 8.11 ) was added. In each release from 8.10 to 8.17, improvements to the GitLab runner were added. We launched review apps ( 8.12 , 8.13 , 8.14 ) and auto deploy ( 8.15 ) to automate the deployment of code into automatically created environments. And with the release of GitLab 9.0, we run deploy boards , which will allow you to monitor the deployment of your applications to different servers.

Analysis and Monitoring

GitLab provides tools for analyzing and monitoring your code and development process. In version ( 8.3 ) a mapping of the project participants' contributions to the development was added, as well as the analytics of the development cycle ( 8.12 , 8.13 , 8.14 ). A time tracking functionality has been added ( 8.14 , 8.16 ). In versions 8.16 and 8.17 , open source Prometheus was added, making it possible to monitor the server running the GitLab instance via the Prometheus console. In GitLab 9.0, integrated monitoring based on Prometheus has been added, built into the GitLab user interface.

Thanks

We are very grateful to our community, whose members create and comment on many tasks, as well as directly add the source code. In version 9.0, more than 130 merge-requests were created by community members , many of whom have made a significant contribution to the development of the project .

In GitLab CE, which is an open source project, more than 47,000 commits have already been made, which is more than twice the number of commits in version 8.1 - 20,000 . Currently, more than 1,500 participants have contributed to the development of GitLab. Thanks you!

Growth

Our team has also grown seriously during this time. At the time of release of version 8.0, GitLab employed less than 25 people from seven countries. Today we have more than 150 people from 37 countries . This growth has allowed us to release three different versions of GitLab: Community Edition (CE), Enterprise Edition Starter (EES) and Enterprise Edition Premium (EEP) .

Unique platform

Recently, application lifecycle management (ALM) tools are evolving towards a single integrated approach. GitLab fully supports this development vector and, as a result, in this version the monitoring functionality is delivered by default, as planned . From now on, you can develop, write code, build, deploy and monitor your application directly from GitLab.

GitLab is a complete and self-contained tool for managing the lifecycle of a single interface application and data storage. Thanks to this integrated approach, development time is shortened (measured by analytics of its cycle), its efficiency is increased, and the development process is normalized.

Use version 9.0 with pleasure!

Meetings at the release of GitLab 9.0

Mitapas about the release of GitLab 9.0 will be held in San Francisco, Denver, Boston, Amsterdam, London and New Orleans.

Join now!

mvp-badge

This month's MVP is Jacopo Beschi .

Thanks to him, it became possible to remove the previously assigned status 'complete' from the todo list item , which allows you to return to the todo task that you marked completed by mistake and, as a result, increases the productivity of the development. Thanks, Jacopo!

Subgroups (CE, EE)

Using GitLab has always been the easiest way to work together on code at all stages of a project’s existence, starting with an idea and ending with a release. Also, users received requests for the implementation of collaboration based on a hierarchy of development teams with separate repositories. In Gitlab 9.0, we are pleased to present a new version of GitLab groups that supports the creation of groups within groups, that is, “subgroups”.

Any subgroup at any level of the hierarchy is a full-fledged GitLab group, which may own several projects (repositories). Thus, the new version of the groups allows you to create a hierarchy of up to 20 levels of nesting.

In this example, the organization (represented by the gitlab-nested group) includes design, backend and frontend teams, each of which has its own group contained in gitlab-nested . design and backend groups have their own subgroups.

Subgroups

Look at the current process of further developing the functionality of groups and leave your wishes here .

Deploy Boards (EEP)

GitLab supports a powerful CI / CD system, in which only for projects on GitLab.com there are more than a thousand handlers (runners). Pipelines performed on them compile and compile software, run automated tests, create review apps, and can even deploy to staging and production. Previously, a deployment report came in which indicated whether the environment update was successful. But what if more details are needed? Or, say, a single interface for viewing information on all deployments in all environments? For large organizations, the answers to these questions become particularly important.

With the release of GitLab 9.0, we are pleased to introduce Deploy Boards for environments using Kubernetes. The Pipelines -> Environments tab provides a single interface for viewing information about the current state and status of the deployment for each environment, up to each sub flow (pod). Developers and other team members can view the progress and deployment status for each individual pod in a familiar development environment without needing access to Kubernetes.

In honor of the launch, Deploy Boards will be available in version 9.0 for free to Enterprise Edition Starter users.

Deploy Boards Documentation

Deploy boards

Task Export (EES)

GitLab already has filtering and search functionality. However, there are situations in which you need to get a list of tasks for external use. For example, to analyze offline or to work with teams that do not use GitLab. In version 9.0 EES, when you click on the download button in the upper right corner of the screen on the task view page, you will be sent an email with a list of tasks in CSV format.

Since this functionality is integrated directly into the task viewer window, you can use filtering and search mechanisms to download a list of exactly the tasks you need. Processing such a request and sending a letter occurs asynchronously in the background, so you can continue to use GitLab immediately after you confirm the request.

More information about exporting tasks can be found here.

Export Issues

Integrated Monitoring (CE, EE)

Having a strong monitoring infrastructure is key to successful application management. It allows you to quickly respond to changes, track their effects and debug if problems arise. However, the creation of such an infrastructure often has a low priority, especially in test environments. As a result, there are cases when the monitoring system is not integrated into the project.

With the release of GitLab 9.0, we are proud to present the first monitoring system fully integrated into the CI / CD pipelines and the source code repository. From now on, GitLab test development environments, such as staging and review apps, use the same monitoring technologies as in the final “battle” environment. This system is implemented using Prometheus .

This version tracks CPU and memory usage by your application running in each Kubernetes environment, and this is just the beginning. In the near future, it is planned to add an assessment of the impact of Merge on performance, support for a wider set of analyzed data, as well as the transfer of monitoring data to Deploy Boards.

Participate in the discussion of the further development of the monitoring system GitLab here .

Project Integration Documentation with Prometheus

Environment monitoring with Prometheus

Performance Improvements (CE, EE)

As usual, we are working hard to improve the performance of GitLab. Version 9.0 introduced a number of changes aimed at a significant acceleration of the system. GitLab EE 9.0 has a number of fixes in Elasticsearch (ES), as well as support for ES 5.1. Following the "cloud native" philosophy, we added support for AWS-hosted and HTTPS Elasticsearch clusters. Improvements in the primary indexing process will speed up the work of large-scale projects on GitLab EE. In addition, a number of minor changes were made to the repository indexing process.

The search algorithm by author and task performer was improved , and unnecessary queries were removed . These changes should be noticeable to most users, since viewing tasks and merge-requests assigned to oneself is a fairly frequent procedure. At GitLab.com, there has already been a significant reduction in transaction time due to these changes.

Take a look at the full list of performance improvements in version 9.0 and do not forget to follow up on further improvements in upcoming releases. GitLab continues to grow faster, especially when working with large-scale projects.

Did you know that GitLab.com is “just” a large-scale implementation of GitLab EE with hundreds of thousands of users? This allows you to assess the scale at which you can work with GitLab EE, and the above-mentioned performance improvements will significantly increase the speed and reliability of GitLab.com.

Transaction timings dropping significantly for issues dashboard

Transaction timings dropping significantly for merge requests dashboard

Database Load Balancing (EE)

Load balancing database queries allows you to disperse the volume of requests and server load. Usually, this requires the use of third-party software, for example pgpool . Starting with version 9.0, GitLab Enterprise Edition supports query distribution when using PostgreSQL.

This approach has many advantages, for example, reducing the load and memory usage of the main database, as well as reducing the response time to queries. In addition, due to load balancing, unnecessarily resource-intensive queries do not affect database queries on other servers, which reduces the likelihood of their negative impact on the operation of GitLab.

The GitLab query balancer also responds to database failures. In cases when the main database does not respond, or a switch to the secondary one occurred, the balancer repeats the operation after a short pause. And in cases where secondary databases do not respond, the dispenser ignores them until they become available again. For the most transparent operation of such a system, it is necessary to use a query balancer (for example, HAProxy) for each host.

It is worth paying attention to the fact that when using the query distribution system there is a problem of delayed copying. For example, when writing and then reading from a secondary database, it is possible that there is no data on this database yet. One way to solve this problem is to use synchronous copying. However, with this method it is possible to significantly increase the processing time of requests due to the delayed copying. Moreover, if for some reason a copy of the data becomes inaccessible, the whole system may stop.

The “sticky sessions” approach is used to solve this problem: when a user initiates writing to the main database, the session of this user continues to use the main base. This continues until the timeout expires (30 seconds), or until the moment when the recorded data becomes available on all secondary databases.

More information about setting up a database balancer is in the "Database Load Balancing" documentation.

Load balancing load

Load Balancing Memory Usage

Load Balancing Timing Improvements

Updated navigation (CE, EE)

At GitLab, most business processes (and not just product development) take place at GitLab.com itself. Therefore, we know exactly how important navigation is. We want to make it smooth, intuitive and effective for your daily tasks, especially for people who use GitLab for several hours every day.

Navigation design is the key to achieving this goal, so at 9.0 we changed the interface by connecting best practices from our designers and feedback from users. At first glance, nothing has changed. This is special. We painstakingly analyzed what is already working well, and changed only problem areas.

We have regrouped (and in some cases merged and renamed) the first and second level tabs in the navigation menu. Activity tab is now embedded in the project tab. The main tabs of the repository, tasks, merge-requests and pipelines are now located respectively from left to right, in the sense of “from idea to production”. The second-level tabs from the Graph tab were regrouped and moved to other places. We thought out where each menu item should be, using data analytics and your wishes. Learn more about the details of the change.

Another major change is the pop-up sidebar. It was replaced by a less obtrusive drop-down menu at the upper left, which does not cover much of the contents of the screen. Previously, we used the drop-down menu for settings: it appeared by clicking on the gear in the upper right on the pages of a project or group. Now the settings have moved to the tabbed navigation interface, which has brought harmony and simplified their use.

In 9.0, we simplified the configuration settings of the project view, so now you can choose what to show on the “home page” of each project: the list of files and the README or current activity. (This is a profile setting that applies to all projects you are viewing.) The first option is the default. Previously, only the README was shown by default, but we wanted something that would help both new and existing users. Therefore, we studied the feedback and user research and stopped at this option.

We also returned the ability to quickly create new projects by simply clicking the + button at the top right.

Navigation

Changing the order of tasks in the board list (CE, EE)

Issue Boards is a great way to manage tasks moving through different stages ("lists") in GitLab to quickly move from idea to production. But users often want to change the order or priority of tasks even within a single list. In version 9.0, you can change the order of tasks in the taskbar list using simple drag and drop.

Learn more about Community Edition Issue Boards in our documentation .

Boards reorder

Milestone Boards (EES)

The GitLab task board allows you to manage task groups in one milestone, but requires you to select the associated filter of the miststone each time you go to it. In GitLab 9.0 EES, you can create a task board associated with a specific mailstore. This will allow you to create unique boards for individual milestones.

As you plan and complete tasks in each new milestone, we assume that you will need new boards. This will allow you to conveniently switch between the Milestones, and while still you can save and look at the previous completed Milestones.

More about Issue Boards for Enterprise Edition in our documentation .

Boards milestone

API v4 (CE, EE)

Our API is a great tool for automating tasks and managing GitLab. We are constantly improving our API to support new features that we add every month to make GitLab a better development environment from start to finish.

Constant iterations have led to several inconsistencies in the existing API. In this release, we present the fourth version of our API. We tried to make it more consistent and compliant with the RESTful API standard.

API 2017 , .

4 , ,

(-) (EEP)

. — , , ( , ), : - , . , . GitLab . .

GitLab 8.5 , GitLab Geo . , GitLab, (mirror) . Geo — ( git fetch ) . Geo , , - : , , .

, GitLab 9.0 . Geo :

LFS, LFS ( - ).
( - ).
.
( - ).
.
-, Geo , , - (production-ready).