In the first release of 2018, we made improvements to the processes of planning, testing, deploying and working with Merge Requests. In addition, this release includes new security testing features, as well as the first version of the Web IDE, which is part of our ambitious Complete DevOps project.
Part of Complete Devops is to maintain powerful security tools. With the previous release, we released static application security testing, and in this we continue to expand security capabilities by adding static testing for Docker containers and dynamic application security testing ( Dynamic Application Security Testing (DAST) ).
The rule of two minutes from Getting Things Done is: if you can do something in two minutes, do it now. Writing a small fix or correcting a typo should not take a lot of time, but this rarely happens when you need to make a stash of changes and switch to another context.
Excessive time costs when working with fixes negatively affect the cycle time, which is especially noticeable in geographically distributed commands - avoiding git stash
can lead to whole days of delay. The new editor , which is the first release of the GitLab Web IDE, simplifies working with such changes from the GitLab interface.
Also this month, we have made many improvements to the epics, merge-requests, monitoring, Geo, Runner, Git LFS, SSH and Auto DevOps.
Further in the article we will dwell on these and other innovations of GitLab 10.4.
George joined GitLab only from the previous version and over the last month made a serious contribution to improving the interface, adding seven Merge-Requests , including fixes for sidebar icons and list hierarchy in user preferences .
Thank you George for his attentiveness and work!
Conducting static code checks is the first step to detect potential security vulnerabilities. However, after deployment, your application is at risk of another category of attacks, for example, using cross-site scripts or unreliable authentication.
We continue to work on automatic detection of security issues and add Dynamic Application Security Testing (DAST) to our application in GitLab 10.4. With it, you can check the live version of the application (for example, the Review App created in previous work) directly from the CI / CD pipeline. Starting with GitLab 10.4.1, Auto DevOps will automatically launch DAST for Review Apps of your applications.
When applications are launched from containers, their code is separated from the code of other containers on the same host, which increases their security. However, even in such cases, application security may be at risk due to problems in the environment on which it is running (for example, vulnerable system libraries).
GitLab 10.4 adds the ability to conduct security checks on the image that contains your application, before merging changes to a stable branch. If, as a result of this check, security problems are found, the corresponding warnings are displayed in the merge-request. Such checks are part of Auto DevOps .
SAST documentation for Docker containers .
In GitLab 10.4, we introduce a beta version of the new Web IDE editor, with which it will be easier and faster to make small fixes and respond to feedback in merge requests, due to the disappearance of the need for stash changes and local switching between branches.
In future releases, we plan to strengthen the integration of Web IDE with merge-requests , improve the functionality of the commit of individual files , as well as add a preview and a web terminal so that everyone can contribute.
While the Web IDE is in the early beta stage, access to it is optional. To get it, go to your profile, go to Settings> Preferences , connect the Web IDE and click Save .
In GitLab CE, it became possible to rebase and fast-forward the merge directly from the merge-quest interface. Now you don’t need to switch between GitLab and the command line; all this can be done inside GitLab.
Previously, this functionality was only available in EE. We added it to CE as a consequence of adding GNOME to GitLab CE .
Documentation on rewind of merzh-requests .
Epic allows you to manage a set of tasks related to a common theme. Often the epic is associated with the development of large functionality, divided into several tasks, work on which is conducted in parallel on a set of Milestone.
Sorting the task list in the epic can be performed according to various criteria, depending on the workflow of the organization. Such criteria can be priority, complexity, feasibility, or execution order.
In some organizations, closed tasks prefer to see at the top of the list, and in others - at the end. In this release we add the ability to change the order of tasks, simply dragging them to the right place in the list - just like in the task boards.
Starting with this version, the GitLab API supports epics. Now you can manage individual epics, their lists and all their attributes (name, description and dates) through the API, which allows your team to create custom and / or automated workflows outside of GitLab.
Also supports the management of lists of tasks Epic , including changing the order of their display.
Since this release, it has become possible to manage group task boards through the API in the same way as project task boards. This innovation adds new automation capabilities and increases the flexibility of managing your team's workflow.
For example, some teams have business requirements for automatically moving tasks between rows of the board in response to certain conditions. Now it can be configured for group task boards through the API.
In this release, it became possible to deploy Prometheus to a connected Kubernetes cluster in one click, which makes it easier to start monitoring the performance of your application than ever. System metrics, such as processor and memory usage, are automatically transferred from Kubernetes, and response metrics, such as delay and throughput, are available through NGINX ingress . To get started, connect the cluster to CI/CD > Clusters
.
If GitLab has Prometheus network access, you can enable integration with Prometheus to analyze and display these metrics directly in GitLab. In the next release, GitLab 10.5, integration will be enabled automatically . Also, it will not require direct access to the network, which will make integration even smoother.
Prometheus deployment documentation on Kubernetes via GitLab .
When authorizing a user, OpenSSH uses a linear search to find the key. This means that SSH operations become slower as the number of users of the GitLab instance grows. For large instances, the request may take considerable time and high write speed to disk, which will slow down the use of Git over SSH.
In GitLab 9.3, a quick SSH key search has been added to GitLab EE. This allows users to log in using fast indexed search in the GitLab database instead of the slow linear search, which was the default. GitLab CE is made for small teams, so previous versions did not include this optimization. However, in order to support Cloud Native Helm Charts in GitLab, all parts of the code must support fast search for SSH keys - so we added this feature in GitLab CE.
Quick Search for SSH Keys in CE .
Determine which files are being tracked by Git LFS using the new LFS tracking status icon. This icon is displayed in blobs and in file lists, including a list of changes in merge requests. This makes it possible to check whether LFS tracks binary files correctly when viewing a merge-request.
Documentation for managing large binary files with Git LFS .
In GitLab 10.2, both Geo and Postgres HA became publicly available separately, but using Geo with HA was possible only in beta.
Configurations that use GitLab Geo with HA are now publicly available. This will allow distributed teams to enjoy the increased speed of Git fetch operations using GitLab Geo and the redundancy of high-available configurations.
GitLab Geo Documentation with HA .
In the previous version, we added browser performance testing to easily determine the impact of changes on the performance of web applications before performing merge. To use this feature, it was necessary to add additional work.
in .gitlab-ci.yml
and adapt it to your needs.
In GitLab 10.4, browser performance testing is included in Auto DevOps , which provides automatic analytics of root page performance with no customization.
If you want to test additional pages, simply add the appropriate paths to the .gitlab-urls.txt
in the root directory of the repository.
Documentation for automatic testing of browser performance .
In GitLab 10.4, we have improved the interface performance interface,
which displays the system metrics derived from Prometheus.
Previously, when tracking metrics at a certain point in time, they were in the description of the graph. Now these metrics are clearly shown in hover. In the next release, we will add generic metrics to the graph description, displaying statistics like maximum throughput or average latency for a certain period of time.
Environment Tracking Documentation .
With the release of GitLab 10.4, Omnibus packages are now available for openSUSE 42.3 .
This release will be the latest with support for openSUSE 42.2, since it is officially discontinued.
OpenSUSE Leap Support Documentation 42.3 .
GitLab Runner uses a cache to speed up execution by reusing existing data between different jobs. But sometimes this leads to contradictory behavior, for example, when one work changes a local copy of the repository, and these changes affect the work of the next.
In GitLab 10.4, we present a new button on the pipelines page, by clicking on which the existing cache for a specific project is cleared, and the new one will start with a fresh one. This solves the dirty run problem.
Runner cache flush documentation .
We are proud to announce that in the GitLab 10.4 version, integration with the Kubernetes cluster has become publicly available. You can add your existing clusters to your project or create new ones using Google Kubernetes
Engine (GKE) a couple of mouse clicks on a new cluster page in the CI / CD section.
The old Kubernetes integration service is still available, but its use is possible only if it was turned on before the GitLab update to 10.4. In future releases, existing data will be transferred to a new cluster page, and the integration page will eventually be deleted. Service templates that are available from the admin area work as before.
GitLab Cluster Documentation .
Scheduled pipelines are very convenient for running repetitive works without user intervention. Usually they are used to perform maintenance tasks or to create nightly builds of your software. But sometimes such tasks need to be performed immediately and manually, and creating an identical environment (for example, adding custom variables) can be difficult and time consuming.
GitLab 10.4 gives you the opportunity to start the planned pipeline manually, directly from the web interface: you will find the “play” button in each schedule in the list - and you can start the pipeline with just one click.
Manual startup documentation for scheduled pipelines .
Also in this release we release GitLab Runner 10.4! GitLab Runner is an open source project that is used to run CI / CD and send the results back to GitLab.
The most important changes are:
docker.allowed_images
will now be able to use global syntax in config.toml
git config --local
- this setting is not available in Git version 1.7.1You will find the full list of changes in CHANGELOG GitLab Runner
GitLab Runner Documentation 10.4 .
Documentation on Omnibus improvements .
With each new release, we are increasingly improving the performance of GitLab. We try not only to speed up every GitLab instance, but also to improve the performance of the entire GitLab.com, with more than a million users.
In GitLab 10.4, we introduced performance improvements for tasks, merge-requests, repositories, and APIs. The most noteworthy of them are:
All performance improvements in our documentation .
Detailed release notes and instructions for updating / installing can be found in the original English post: GitLab 10.4 released with Dynamic Security Testing and Web IDE (beta) .
Rishavant and sgnl_05 also worked on translation from English.
Source: https://habr.com/ru/post/348086/