GitLab kun je vergelijken met het bekendere GitHub, maar bevat een aantal subtiele verschillen. Het is een omgeving voor het beheren van Git-repositories on-premises en wordt uitgegeven onder de MIT Expat-licentie en ontwikkeld in Ruby on Rails. Het is beschikbaar in twee versies, namelijk de gratis te gebruiken Community Edition en een betaalde Enterprise Edition met meer functies die op grote bedrijven zijn gericht. De twee smaken worden op deze pagina uiteengezet. Het ontwikkelteam heeft GitLab 9.0, 8.17.4, 8.16.8, en 8.15.8 uitgebracht met de volgende aankondigingen:
GitLab 9.0 Released with Subgroups and Deploy Boards
Today we are releasing GitLab 9.0, 18 months after releasing 8.0. We've made significant advances to GitLab during this period, shipping a version every single month on the 22nd. Let's quickly recap how far we've come since 8.0, and see those features dovetailing into today's 9.0 release. Or jump ahead to 9.0 features.
Idea to Production
In the last several releases, GitLab has transformed how development teams get from idea to production. In just a few minutes, you can deploy GitLab to a container scheduler, add CI/CD with auto deployed review apps, utilize ChatOps, and analyze your cycle time. With 9.0 you can now watch your deploys with deploy boards and monitor application performance with Prometheus. Building on our Master Plan, GitLab 9.0 truly delivers the entire DevOps toolchain.
Usability and Design
In 8.0, we refreshed GitLab's look and feel, modernizing almost every UI element and significantly improving usability. (We had even updated our logo a few months prior.) Since then, we have continued to invest in design, ramping up our UX design and research team, who are dedicated to improving usability and solving major pain points, everything from small CSS tweaks, to major UX flows. In each 8.x release we have iteratively evolved the design. And with GitLab 9.0, we made huge strides in simplifying our global, group, and project navigation, a crucial enhancement as GitLab's feature set becomes increasingly powerful.
Collaboration on Digital Work
GitLab helps you collaborate on digital work. We made many enhancements to issues, a core part of collaboration in GitLab. This includes weights (8.3), linking to merge requests (8.3), moving an issue to another project (8.6), and a powerful filter/search interface (8.16). We also released issue boards (8.11), providing a simple mechanism for issue workflow management using stages ("lists", in GitLab parlance). GitLab 9.0 continues to enhance boards further, by improving its integration with milestones.
We are excited to ship subgroups in GitLab 9.0, another huge step in furthering GitLab collaboration. This powerful new paradigm of groups within groups allows for truly team-based and team-first collaboration in even very large organizations with many different departments. We're on a mission to enable everyone to contribute. 9.0 continues to help break down silos wherever you work so that indeed everyone in your organization can contribute.
Code Review and Code Collaboration
We've continued to improve code review and code collaboration in GitLab since 8.0, including features such as merge when pipeline succeeds (8.3), code diffs (8.4, 8.5, 8.7, 8.10, 8.15), a conflict editor (8.11, 8.13), merge request versions (8.12), blocking merge until discussions resolved (8.14), toggling approvals (8.16), as well as squash and merge (8.17). Many of these and other features involve the merge request widget. So in GitLab 9.0, we are revamping its design to accommodate the many existing and upcoming features that integrate with it.
Continuous Integration
8.0 was a pivotal release as it fully integrated continuous integration (CI) into GitLab itself. Subsequently, new CI features were implemented into the API (8.4) and pipeline events were exposed through webhooks (8.11). Pipelines were also integrated into merge requests (8.11, 8.17) and commits (8.13), as well as its own visual graph (8.11). GitLab runner was improved in every release from 8.10 to 8.17. We released review apps (8.12, 8.13, 8.14) and auto deploy (8.15) to automatically deploy code into automatically created environments. And now with GitLab 9.0, we are shipping deploy boards, allowing you track how your app is being deployed to multiple servers.
Feedback and Insight
GitLab also provides you feedback and insight into your code and development process. We released contribution analytics (8.3) and cycle analytics (8.12, 8.13, 8.14). We released time tracking (8.14, 8.16). In 8.16 and 8.17, we shipped open source Prometheus to extend that feedback into monitoring the server that hosts your GitLab instance, through the Prometheus console. In GitLab 9.0, we are releasing environment monitoring integrated into the GitLab UI itself, building on top of the Prometheus foundation.
Subgroups CE EE
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.
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.
Export Issues EES
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.
Environment Monitoring CE EE
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.
Performance Improvements CE EE
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.
Database Load Balancing EE
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.
Updated Navigation CE EE
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 EE
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.
Boards with Milestones EES
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.
API v4 CE EE
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.
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:Disaster Recovery in Alpha is available to all Enterprise Edition Premium customers as part of GitLab Geo.
- 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.
- While the new features above are in alpha, the core Geo feature, which is to clone and fetch projects over large distances, is still production-ready like before.
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.0Deprecations
- Native Unicode Emoji CE EE
- New Branch for Bare Projects CE EE
- GitLab CI CE EE
- Merge Request Widget Usability CE EE
- Gitaly CE EE
- Create Mattermost Team when Creating GitLab Group CE EE
- Group search and filtering CE EE
- Paginated environments CE EE
- Tokenized Filter and Search in Issues and Merge Requests CE EE
- Impersonation Tokens CE EE
- GitLab Pages artifacts cleaned after deployment CE EE
- Comments in diffs CE EE
- Omnibus GitLab Package Improvements CE EE
- Pipeline triggers with User permissions CE EE
- New default value for CI variable "cache:key" CE EE
- Blocking manual actions in pipelines CE EE
- More control over HTTP Strict Transport Security CE EE
- GitLab Runner Deprecation
- Git-Annex deprecation
- GitLab Pages IP on GitLab.com
GitLab 8.17.4, 8.16.8, and 8.15.8 Released
Today we are releasing versions 8.17.4, 8.16.8, and 8.15.8 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain several security fixes, including an important security fix for a critical information disclosure vulnerability, protection against Server-Side Request Forgery (SSRF) attacks, a fix for some links vulnerable to tabnabbing, a fix for a flaw that could leak private email addresses in Atom feeds, and a fix for private repository data leakage into ElasticSearch (EE-specific). We strongly recommend that all affected GitLab installations be upgraded to one of these versions immediately.
Information Disclosure in Issue and Merge Request Trackers
During an internal code review a critical vulnerability in the GitLab Issue and Merge Request trackers was discovered. This vulnerability could allow a user with access to assign ownership of an issue or merge request to another user to disclose that user's private token, email token, email address, and encrypted OTP secret. Reporter-level access to a GitLab project is required to exploit this flaw.
This vulnerability is the result of a bug in the serialization of a user object and was introduced in GitLab 8.7.0. Please see the issue for more details.
This issue has been assigned CVE-2017-0882.
Versions affectedWe strongly recommend that all installations running a version mentioned above be upgraded as soon as possible.
- 8.7.0 through 8.15.7
- 8.16.0 through 8.16.7
- 8.17.0 through 8.17.3
Post-Upgrade Steps
Due to the nature of this vulnerability it is possible that sensitive user tokens have been cached by proxies or web browsers. We therefore recommend that administrators reset private tokens and incoming email tokens for all users. A rake task for performing token resets is included with this announcement.
Encrypted One-Time Password (OTP) secrets may also have been leaked by the vulnerability. These secrets are encrypted, require the key for decrypting the secret, and cannot be used on their own without a copy of the user password, however we are still recommending that all users who utilize One-Time Passwords disable and then re-enable their 2FA for all GitLab instances. This will reset the OTP secret.
Other fixes in 8.17.4, 8.16.8, and 8.15.8
- SSRF when importing a project from a Repo by URL
- Links in Environments tab vulnerable to tabnabbing
- Accounts with email set to "Do not show on profile" have addresses exposed in public atom feed
- Elasticsearch returns internal code, snippets, issues, wiki pages and MRs on public projects (EE only)
- Upgrade barometer
:strip_exif()/i/2000869175.png?f=thumbmedium)
:strip_icc():strip_exif()/u/126511/avatar.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/140697/crop6180fb9103afa_cropped.jpg?f=community){kind=small}
