This month's Most Valuable Person (MVP) is Jacopo Beschi Jacopo made it possible to undo marking a todo item as done in the todos list. This is a huge productivity enhancement that helps you recover from mistakes in managing todos. Thanks Jacopo!

Subgroups ce ees eep GitLab has always been the simplest way for people to collaborate on code in a project. Just create a project, and you're on your way from idea to production. Users have also told us that they want GitLab to be a team-based collaboration tool that supports hierarchical team structures sharing different code repositories. With 9.0, we are excited to ship our brand new version of GitLab groups that allows for groups within groups, i.e. "subgroups". Each group, at each level, is itself a first-class citizen GitLab group, with the ability to have multiple projects. The new version of groups thus enables you to have a hierarchy of code repositories. You can create up to 20 levels of subgroups, giving you an incredible level of flexibility. In this example, the organization represented by the gitlab-nested group has a design team, a backend team, and a frontend team, each represented by a group within the gitlab-nested group. The design and backend groups have further subgroups within them. Feel free to look at and provide feedback on what we are working on for groups in future releases of GitLab. Learn more about subgroups in our docs

Deploy Boards eep GitLab has an incredibly powerful CI/CD system, with over a thousand runners executing pipelines for GitLab.com projects alone. These pipelines perform builds to compile and package software, run automated tests, spawn review apps, and can even deploy software to staging and production. To date, these deployments would report back whether the environment was successfully updated, but what if you wanted more fidelity? Or a single pane to view all deployments across all environments? For larger organizations, the answers to these questions become particularly important. Today with 9.0, we are excited to release Deploy Boards for environments running on Kubernetes. The Environments page of Pipelines now offers a single place to view the current health and deployment status of each environment, displaying the specific status of each pod in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes. To celebrate the launch, Deploy Boards will be available in 9.0 as a free trial for Enterprise Edition Starter customers. Learn more about Deploy Boards in our docs

Export Issues ees eep GitLab already enables you to filter, search, and navigate through the many issues you use daily. But users say they want a snapshot of issues for offline analysis or to communicate with other teams who may not be in GitLab just yet. With 9.0 EES, GitLab will email you a CSV export of issues if you click the download button at the top right in the issue list view. We designed and integrated the feature directly into the project issue list view. This allows you to leverage the existing powerful filter and search capability so that you can export exactly just the issues you care about. The actual processing and email sending happens asynchronously in the background once you confirm the action, so that it gets out of your way and you can continue to use GitLab as normal. Learn more about exporting issues in CSV in our docs

Environment Monitoring ce ees eep A robust monitoring infrastructure is crucial to operating a successful application. It ensures your app is responsive, provides valuable insight into the impact of changes, and enables quick debugging when problems occur. However setting this infrastructure up is often a lower priority, in particular for non-production environments, and it is often not integrated with the rest of your toolchain. With GitLab 9.0, we are proud to introduce the first monitoring system that is fully integrated with your CI/CD pipelines and source code repository. Leveraging Prometheus, GitLab will now bring the same technology used for production systems to development environments like staging and even review apps. In this initial release we are tracking the CPU and Memory utilization of your app running on each Kubernetes based environment, and this is only the beginning. In the near feature we will gauge the performance impact of a merge, support a much broader range of application metrics, and fuse monitoring data with Deploy Boards. Participate in the discussion and future of performance monitoring with GitLab here. Learn more about the Prometheus project integration in our docs

Performance Improvements ce ees eep As with every release, we've worked hard to make GitLab faster. With 9.0 in particular, we've put a particular focus on noticeable performance improvements across the board. Elasticsearch (ES) gets an upgrade in GitLab EE 9.0, with support for ES 5.1 and a host of smaller fixes. In accordance with our "cloud native" philosophy, we've added support for AWS-hosted and HTTPS Elasticsearch clusters. Larger GitLab EE installations will benefit from improvements in the initial indexing process, and minor performance improvements have been made to repository indexing. The improvements to the dashboards were focused on more efficient searching by author or assignee, and removing unnecessary queries. As the most common use for the dashboard is to view issues or merge requests assigned to you, this should be noticeable for most users. On GitLab.com, we saw transaction timings drop significantly for issues and merge requests. Take a look at the full list of performance improvements in 9.0 and keep an eye out for further improvements in upcoming releases as GitLab continues to get faster, especially for large installations. Did you know, GitLab.com is "merely" a massive-scale implementation of GitLab EE with hundreds of thousands of users? This just shows the level of scale that you can run GitLab EE and these performance improvements should start making a noticeable difference to 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 ees eep Load balancing of database queries allows one to spread the load and impact of queries across multiple database servers. Traditionally this involves additional software such as pgpool. Starting with 9.0, GitLab Enterprise Edition supports load balancing of queries when using PostgreSQL. Load balancing queries can bring many benefits, such as reducing the load and memory usage of the primary, and reducing response timings. Spreading the load also means that badly behaving database queries will not impact queries executing on a different database server, reducing the likelihood of such queries negatively affecting a GitLab installation. GitLab's load balancer also responds to database failovers. When a primary is unresponsive or was changed to a secondary, the load balancer will wait a brief moment before retrying an operation. When secondaries become unavailable, they are ignored until they become available again. For this to work in the most transparent way you will need to use a load balancer (e.g. HAProxy) for every database host. One problem of load balancing is dealing with replication lag. For example, if a write happens and you then read from a secondary it's possible for said secondary to not yet have the data. One way of dealing with this is to use synchronous replication. However, synchronous replication is not ideal as replication lag could cause queries to take a very long time. Furthermore, if a replica were to become unavailable the whole system can grind to a halt. To work around this the database load balancer uses "sticky sessions". When a user triggers a write to the primary the user's session will keep using the primary. Session sticking is disabled again once a timeout expires (30 seconds), or when the written data is available on all secondaries. For more information on how to set up database load balancing you can refer to the documentation section "Database Load Balancing".

Here at GitLab, most of our business functions (not just product development) occur on GitLab.com itself. So we definitely understand the importance of navigation. We want to make it frictionless, intuitive, and efficient for you to perform your daily tasks, especially if you are using GitLab for several hours each day. Navigation design is a crucial component in achieving that, and with 9.0, we have modernized the interface, leveraging best practices from our design team, as well as incorporating feedback from user research. At first glance, it doesn't seem like a lot has changed. But that was intentional. We meticulously analyzed what was already working well, and changed only the problem areas. The menu items in the tabbed navigation interface have been re-arranged (and in some cases, merged and renamed) for both the main and subtabs. The activity tab is now a subtab of the project tab. The main tabs of repository, issues, merge requests, and pipelines and now positioned from left to right in that order, reflecting the idea to production flow. The subtabs in the main graph tab have been re-arranged and placed in other locations. Again, we carefully considered where each menu should be located drawing from feedback and analysis. Read more about the details of the change. Another notable change is the pop-in sidebar. That has been now replaced by a less intrusive dropdown menu in the top left, that doesn't unnecessarily cover too much screen content. Previously there was a dropdown menu for settings, accessed from a cog icon at the top right for the project and group pages. These have been now pulled into the existing tabbed menu interface, harmonizing and simplifying the entire experience. In 9.0, we simplified the project view configuration settings so that you can now choose between viewing (1) Files and README or (2) Activity on the main project tab for any project. (This is a profile setting that applies to all projects you view.) The first option is the default. Previously, we had a third option for viewing just the README, which was the default. We wanted something that was helpful for both new and existing users, and based on user feedback and research, we are opting for this design. We also brought back the ability the create a new project quickly, by simply clicking the + button at the top right.

Reorder Issues in Board List ce ees eep Issue Boards are a great way to manage issues moving through the different stages ("lists" in GitLab), in order to quickly get an idea to production. But users often want to further represent order or priority of issues within a single list. With 9.0, you can now reorder issues within an issue board list, using the intuitive and existing drag and drop mechanism. Learn more about Issue Boards for Community Edition in our docs.

Boards with Milestones ees eep A GitLab Issue Board enables you to manage a group of issues within a single milestone, but requires you to select the associated milestone filter each time you navigate to it. With GitLab 9.0 EES, you can now create an Issue Board that is associated to a specific milestone. This allows you to create unique boards for individual milestones. As you plan and execute work in each new milestone, we suggest you keep creating new boards. This allows you to conveniently straddle between milestones, while also allowing you to save and look back at previous completed milestones. Learn more about Issue Boards for Enterprise Edition in our docs.

API v4 ce ees eep Our API is a great way to automate tasks, control and automate GitLab in new and powerful ways. Over time, we have continued to improve our API to make it more complete and support the new features we add every month to make GitLab the best end-to-end development environment. This constant iteration has resulted in a few inconsistencies in our existing API. Today we are announcing v4 of our API, which aims to make the API more consistent and more RESTful. We will continue to support v3 of the API until August 2017 and so we encourage you to make any necessary changes to applications that use the v3 API. Take a look at the changes in v4 to see what's different.

Disaster Recovery Alpha eep Regardless of the size of your company, you need to make sure that your infrastructure is resilient to any kind of natural or human-induced disasters that can happen. One of the best practices in this case is to have a least two servers (one primary, one secondary) in two different locations to make sure that if the primary server goes down, the other one can take over. Having this in place is critical for any teams to make sure you reduce the downtime as much as possible, and reduce the risk of data loss. We have received many requests to offer a disaster recovery solution built in GitLab and today we are introducing a first step towards supporting this. Since GitLab 8.5, GitLab ships with Geo, a feature that lets you have one or more secondary instances that mirror your main GitLab instance. Geo's primary goal was to drastically speed up cloning and fetching projects over large distances. While Geo works really well for this use case, it has one point that prevents us to use this technology to support a full disaster recovery scenario: files that are saved on disk were not replicated. This is what we are actively working on and with GitLab 9.0, we are releasing a first step towards providing support for Disaster Recovery scenarios. We call it Disaster Recovery in Alpha. A bunch of important changes to Geo have been introduced with this release: If you use LFS, LFS objects will automatically be replicated to the secondary nodes (Merge request).

All file uploads are now recorded in the database (Merge request). This will allow us to replicate those files in a future iteration.

There is a new process to automatically backfill repositories (Merge request).

You can now disable a secondary node through the UI.

Both GitLab Geo and Disaster Recovery are under development and not production-ready. To enable Disaster Recovery in Alpha, refer to the documentation. Disaster Recovery in Alpha is available to all Enterprise Edition Premium customers as part of GitLab Geo. On a sidenote, due to PostgreSQL's upgrade happening with GitLab 9.0, GitLab Geo 8.x is not compatible with GitLab Geo 9.0 and requires a manual update. If you are an existing Geo user, please read the upgrade instructions before upgrading to GitLab 9.0.

Other Improvements in GitLab 9.0

Deprecations GitLab Runner Deprecation Please note that GitLab Runners prior to 9.0 utilize API v3, and therefore are deprecated along with the v3 API. Runners version 9.0 and above utilize the new v4 API, requiring a minimum of GitLab 9.0. Due: August 2017. Git-Annex deprecation As previously announced, support for Git-Annex has been deprecated in GitLab 9.0. Read through the Git-Annex to Git-LFS migration guide. Due: today. GitLab Pages IP on GitLab.com We've changed the IP address of GitLab Pages server on GitLab.com. Your DNS A record needs update. For more info, please read the blog post "We are changing the IP of GitLab Pages on GitLab.com". Due: March 31st, 2017 at 23:59h UTC.

Upgrade barometer To upgrade to GitLab 9.0, downtime is required. Larger instances (>1000 users) should expect about 15 minutes of downtime. The specific migrations requiring downtime or taking significant time are described below. Some columns are renamed. This operation requires downtime.

A new column is added to users table, which does not require downtime but may take some time to complete.

The builds table is updated, which does not require downtime but may take some time depending on your CI usage. GitLab 9.0 introduces a new version of our API. While existing calls to API v3 will continue to work until August 2017, we advise you to make any necessary changes to applications that use the v3 API. Read the documentation to learn more. Because of PostgreSQL's upgrade, GitLab 9.0 introduces a breaking change to GitLab Geo. If you are an existing Geo user, please refer to the documentation before upgrading to 9.0. Note We assume you are upgrading from the latest version. If not, then also consult the upgrade barometers of any intermediate versions you are skipping. If you are upgrading from a GitLab version prior to 8.0 and you have CI enabled, you have to upgrade to GitLab 8.0 first. New configuration options have been introduced in the omnibus-gitlab packages. To check what changed compared to your /etc/gitlab/gitlab.rb configuration file, run sudo gitlab-ctl diff-config . Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations file. If you're GitLab EE user, please be aware that in 9.0 release we bumped the required version of Elasticsearch from 2.4.x to 5.1.x. Please update it following the official documentation. Indexes created by Elasticsearch 2.4.x can be read by Elasticsearch 5.1.x.

Changelog Please check out the changelog to see all the named changes: GitLab CE

GitLab EE Installing If you are setting up a new GitLab installation please see the download GitLab page. Updating Check out our update page. GitLab Products We offer four different products for you and your company: GitLab Community Edition (CE) : Open source, self-hosted solution of GitLab. Ideal for personal projects or small teams with minimal user management and workflow control needs. Every feature available in GitLab CE, is also available on GitLab Enterprise Edition (Starter and Premium), and GitLab.com.

: Open source, self-hosted solution of GitLab. Ideal for personal projects or small teams with minimal user management and workflow control needs. Every feature available in GitLab CE, is also available on GitLab Enterprise Edition (Starter and Premium), and GitLab.com. GitLab Enterprise Edition (EE) : Open core, self-hosted, fully featured solution of GitLab. Available in two different subscriptions: GitLab Enterprise Edition Starter (EES) : Ideal for co-located teams who need additional security and workflow controls for their professional projects. GitLab Enterprise Edition Premium (EEP) : Ideal for distributed teams who need advanced workflow controls, premium features, High Availability, and Premium Support.

: Open core, self-hosted, fully featured solution of GitLab. Available in two different subscriptions: GitLab.com: Free GitLab solution, which runs on top of GitLab EES, hosted by GitLab, Inc. Ideal for individuals who want to get their projects up and running quickly. Administrated by GitLab (users don't have access to admin settings).