How does the engineering workflow look like after enabling the Gitlab merge train

In the last post, we talked about the merge train of Gitlab CI and why enabling it can guard against breaking the HEAD in the following scenario:

• two merge requests independently passing the CI test suite — which means either of them is ready to merge to the target branch;

• they won’t cause any merge conflict to each other — which means they are ready to merge after another;

• BUT, they can cause test suite failure once they merge after another — because the continuous integration process never had chance to test the code when they get merged together.

We talked about how merge train can guard against the above scenario in the last post.

In this post, we try to give a visual about the Gitlab based code review, continuous integration, merge to target branch in our daily merge request process.

Why is it important to build a disciplined full cycle development platform in early stage — even our team is still small?

For a company building modern software, having a disciplined development pipeline at early stage is crucial not only to the product quality, but also crucial to the engineering team culture. It helps fellow engineers to build trust to each other, and it helps the development team to grow both the sense-of-ownership and collaboration, which is foundation of product quality.

With a development platform, we won’t put an engineer into the situation that he/she did a wonderful feature development, which is a very rewarding moment; but the system beyond their control blocks their features from being rolled out to the production, which could become an extremely frustrating moment (see the example described in the beginning of this post).

That’s why a lot of well established companies and large enough late stage startups (let’s speak the word of ‘unicorn’) have a team of internal development platform/tools to help development team can achieve their maximum velocity and efficiency.

But can an early stage team afford building it?

Building a disciplined full cycle development platform with Gitlab

The question is not if building an internal development platform is valuable to a small team; instead, the question is whether a small team can afford building a very disciplined development platform. In this section, we are going to walk through how we can build a reasonably disciplined internal development platform with Gitlab.

Gitlab’s runner is the ‘battery included’ continuous integration system inside Gitlab. Instead of owning and maintaining our own Jenkin’s cluster, Gitlab runner can run the test and build jobs for us. We can configure Gitlab system to run jobs (see the “Build and Test” in the above diagram) once a merge request is created toward a specific branch — see how to configure the continuous integration pipeline with gitlab-ci.yml for details.

At the same time, Gitlab provides the ‘battery included’ code review system in the merge request page as well (See the “Code Review” in the above diagram). We don’t necessarily need to setup external code review tools like Gerrit either. Here we can setup various approval rules such as there must be 2+ approvals before a merge request can be allowed to merge to the target branch.

Then we enable merge train in Gitlab so that we can guard against ‘two good merge requests make a broken HEAD’ problem I talked above in the previous post (See the “merge train” setp in the above diagram).

With these simple configuration and setup, and without writing any in-house pipeline infrastructure, we have built a reasonably complete development platform for our developers to work with each other.

The important thing is that a senior engineer can build this internal development platform within a couple of days at the very beginning of the team (he does not need to be super ‘DevOps’ savvy), including the research and trial & fail process, and easily maintains this internal development platform as his part time job. This early investment can make the engineering team a huge runway to gain velocity in the long run.

Summary:

• An early team can build a robust development platform from day 1 if the team choose to outsource the “undifferentiated heavy lifting” to services like Gitlab.

• A quick and easy to set up development platform (pretty comprehensive one) has been walked through here in this post.