From 13 years of using GitLab to now, watching the rapid evolution of this software, or very emotional.

With the release of GitLab V13, almost any company can quickly acquire the ability to scale DevOps deployments in production, highly transparent application management, and rapid release iterations as easily as a major company.

Let’s briefly review the development history of GitLab’s CI/CD function.

The heavy elephant is ready to dance

At the end of April 2015, a blog with an exclamation mark was officially published as GitLab on Raspberry Pi 2! GitLab, which has long been criticized for eating CPU and memory, was able to run on raspberry PI, and officials began a high-frequency software update iteration.

Stage 1: Start to support CI function and use automation to improve efficiency

At the end of June of that year, GitLab v7.12 was released with strategic importance. This release supports SAML authentication, Merge Request permission (similar to GitHub’s manual Merge permission), and most importantly: The original CI function has been reconstructed to support.gitlab-ci.yml using CI configuration file and built-in WebHook function. GitLab V8.0 was released in September of that year with a new interface and CI integration by default.

Those familiar with CI know that the existence of an independent CI configuration file is the beginning of “Infrastructure as Code”. Travis CI, founded in 2010, enables GitHub users to fill in only declarative configuration. The pleasure of leaving the rest to CI robots.

However, not all projects and content are suitable for public network deployment and use of public services. For various reasons, we still need a similar service that can run in an internal network environment. As this large commercial, privatized deployment software began to support this, the CI technology inclusion wave began. Although the open source software Drone focusing on CI functions was launched one year earlier than GitLab CI, GitLab has been used by many large companies at the moment, and more companies began to try to migrate the old system to it, such as taobao (Alibaba Group), the company I worked for at that time.

Then, in late March 2016, GitLab Runner V1.1 was officially released with automatic scaling support, and a year later, in March 2017, GitLab V9.0 with support for subgrouping and a more intuitive project deployment panel. At this point, any company can quickly experience the full CI process using traditional installation or container deployment in hours to minutes.

The second stage: embrace K8S ecology, improve CD functions and complete the layout of the whole development life cycle

In the second half of 2017, on September 22, GitLab officially released V10.0, which further improved the group Issue panel and brought a new Auto DevOps feature, starting to shift the focus from CI to CD. On June 22, 2018, as Kubernetes was in its heyday, GitLab V11.0 officially further integrated Kubernetes with Auto DevOps, and added a Web IDE, security scanning, and license scanning.

At this point, if you choose to use the GitLab “Service family bucket”, Auto DevOps covers your entire production lifecycle: after submitting code, build, test, quality scan, security scan, license scan, application build, application packaging, performance testing, automated deployment, and application monitoring. Of course, there are also knowledge management functions based on project planning, discussion and questions that have been iterated since the 8.0 era.

Stage three: Improve the development experience in the cloud era

On June 22, 2019, V12.0 was launched. The most important feature of the.gitlab-Ci. yML configuration file, which was introduced four years ago, can be extended and modularized using the extends method, which means that the repetitive CI configuration content in multiple projects can be reduced. Users don’t have to work hard to stuff some common content into scripts and services called by CI, support “sequential merge train”, optimize the container warehouse experience, provide project dependency lists, enhance the Web IDE, and users can directly access the project development environment from the Web browser. There is no need for local configuration and even quick use of Jupyter Book based on GitLab.

Last year, in May 2020, GitLab V13.0 arrived, which further optimized the online editor and the writing experience of.gitlab-ci.yml profiles, and added a new CI trigger that could filter and trigger builds in Kanban by author or branch. At the same time, GitLab Runner V13.0 has been released, and supports the passing of environment variables from.env files, which further reduces the problem of CI configuration file bloat in multiple environments, and enables the centralized management of environment variables in the warehouse, avoiding the scattering of application core information in the system configuration of various warehouse groups. Gitlab-based projects can even be deployed directly into ECS.

In the future?

In the future, GitLab will also continue to focus on improving the experience and efficiency of the whole life cycle of production and development, so as to make development collaboration more efficient and pleasant, such as more efficient and easy to use collaboration kanban, transaction tracking system, better knowledge management and document management system.

With the development of hardware/network in the past two years, whether it is consumer hardware or cloud ecosystem, it will bring about the “retaliatory” development of software. I believe that over time, with the further powerful and perfect Web IDE, the demand for the performance of developers’ devices can be further reduced. It is also possible to code on a lightweight netbook or even an iPad for some heavy-duty projects. I will write a separate post about my past practices and problems.

Meaning of using GitLab

Before talking about meaning, make sure you and your team are the audience. If you have a ready-made R&D process management system, CI system, CD system, monitoring system, etc. Or if you’re an indie developer, a “loner” who doesn’t want to collaborate on product development and just use it for code storage, you’ll probably find it complex and resource-hungry.

But for companies ranging from a few people to tens of thousands, GitLab is a good choice. There are even some open code hosting platforms we’ve all heard about, based on GitLab modifications, that testify to the software’s underlying strengths.

For product development teams that need it, things are inherently “transparent” around or based on open source software such as GitLab for collaboration and production deployment, product design, and work becomes more orderly and easier. For companies, the security of digital assets is guaranteed, the quality of products is “fundamentally” improved, and the human cost is reduced, compared to the benefits of not using or abusing infrastructure software.

Whether there is a small and beautiful choice

As mentioned earlier, GitLab is a bit “heavy” for “individuals” or companies that don’t want to use it heavily. So is there a lightweight way to use it? Or is there an alternative?

Apparently there is, and in the next post, I’ll talk about how to “scientifically” use the old version of GitLab and its excellent competitor, Gitea + Drone.

The last

If you are interested in using GitLab, check out some of my previous articles on how to upgrade, maintain, and use the little details.

— EOF

This article is published under a SIGNATURE 4.0 International (CC BY 4.0) license. Signature 4.0 International (CC BY 4.0)

Author: Su Yang

Creation time: feb 23, 2021 statistical word count: 3432 words reading time: 7 minutes to read this article links: soulteary.com/2021/02/23/…