The first commit to GitLab (!!) was 10 years ago. Today, it’s an entirely different world: DevOps is increasingly mainstream and there's a DevOps platform revolution.
We didn’t have a crystal ball back then, but we did try to create a product, a culture and a company that reflected what we thought mattered most. Here’s a look back at 10 key decisions we made that still have impact:
-
Work in parallel: When we started, it was clear the waterfall method of software development - where one stage waited on another stage and nothing happened independently - slowed everything. We decided right from the beginning that a “work in parallel” philosophy would be fundamental to our culture and our behaviors. Also, such a philosophy naturally supported everything else we did, including bringing CI and CD together and operating as an all-remote company. Working in parallel is also vital to success with DevOps.
-
CI, meet git: To merge dev and ops you have to merge development and operations. We weren’t really sure bringing CI together with a git repository was the right step to take, but we tried it and it worked. Now, developers expect CI to be perfectly integrated into their daily work, and, more and more, they are using a DevOps platform to centralize CI and CD.
-
Cloud native: We’ve been talking about Kubernetes and the options made possible by cloud-native development since 2017. We’re true believers in supporting the ability to embrace cloud-native technology and patterns. The concept of cloud native enables teams to deliver better software faster, break down their applications into microservices and focus engineering time on delivering value to their customers - not on maintaining brittle infrastructure.
-
The mighty merge request: We doubled down on the idea of a merge request, making it the hub of absolutely everything. Merge requests are not only the gateway to production, but all the other critical steps, such as security checks, which can be found in there as well. Plus, the merge request serves as a living record of changes and is essential for better code review.
-
Developer-first security: For developers to have ownership of security, they need scanning early in the process and results in their workflow. That’s why developer-first security is at the heart of our DevOps Platform.
-
A complete definition of security: Security isn’t a “one and done” effort and our DevOps Platform enables us to offer a broad spectrum of security scans that goes far beyond just SAST and DAST. From scanning for dependencies or looking at containers, we cover all the security bases in a single platform.
-
All remote, all the time: With no corporate headquarters and employees in 65 countries and regions (as of October 2021), we’re all remote and proud of it. This decision transformed into a corporate value that has influenced our choices and behaviors.
-
Asynchronous communication: A natural result of being remote, asynchronous communication is something we take seriously. We’re a “handbook first” organization, meaning we write everything down so information is as self-service as possible. We also carefully consider what time is spent in meetings, limiting their frequency and regularly asking ourselves if “asynchronous” is better. This has allowed us to successfully have employees in nearly every time zone around the world and follow the working in parallel philosophy.
-
Visibility: Planning is critical, but it’s equally important to pair it with visibility so everyone knows what’s happening and where it’s happening. Giving context for the original plan to all team members throughout the DevOps lifecycle, how the plan has changed, and what the implementation looks like in the end is a critical advantage to a single DevOps platform. Without this, time is wasted trying to update multiple systems with issue status, or having conflicting information in independent tools.
-
Measure the results: We firmly believe it’s important to know how the stages of the SDLC are going, in detail. After all, if you can’t measure your results, how can you know things are moving in the right direction? Many DevOps teams don’t or can’t measure, but that can make it difficult to convince management of the value of the methodology. A DevOps platform makes measurement easy.
