Interview With GitLab CEO Sid Sijbrandij

Earlier this month, I was fortunate to have a one-on-one interview with GitLab CEO and co-founder Sid Sijbrandij.  My focus was to talk about the last twelve months at GitLab and to inquire on some future enhancements that may be in the works.

John Vester: I remember sitting down with Job van der Voort just over a year ago, talking about the latest features with GitLab 9.0.  Since that time, so many features have been packed into the subsequent releases, as covered by DZone:

• GitLab 9.0 — Now and Looking Ahead: An Interview With Job van der Voort (67.3k views)

• GitLab Release 9.1: Three Big Additions (63.9k views)

• GitLab Moves to DCO, Stands to Gain Debian and GNOME (61.7k views)

• GitLab Making Software Development Great Again (61.6k views)

• 10-4 Good Buddy, GitLab's Latest Features Are Welcome to the Channel (51.8k views)

• GitLab Opens CI/CD to GitHub Users (25.1k views)

• GitLab 10.6 Includes Native Integration into Google Kubernetes Engine (GKE) (17.2k views)

With an average page view count at ~50k, I truly believe the Information Technology community remains tuned in with GitLab. As a CEO, this has to make you happy. 

If we were to go back to the time when 9.0 was released, what future expectations did you have which have not found their way into a GitLab release?

I personally can't remember anything we didn't ship. However, there are always features that are considered overdue, including batch comments on merge requests, real-time editing of issue descriptions, merge trains and sticky runners.

As a company committed to transparency, we’re very open with our community about the status of our release cycles and when to anticipate updates.

With all of the features that have been deployed, what enhancement have you seen users embrace the most?

The use of GitLab’s CI has been off the charts. We've heard from customers like Ticketmaster that adopting GitLab CI can transform their entire software development lifecycle.

For example, the Ticketmaster mobile development team was able to deliver on the longstanding goal of weekly releases after implementing GitLab CI. We have also heard from the developer community that GitLab’s CI solution offers a seamless experience and enables developers to easily monitor the progress of tests and build pipelines while deploying with confidence.

Allowing GitHub users access to the GitLab CI/CD process was an amazing enhancement. What response have you seen from your customers as a result of this new ability? Has anyone from GitHub reached out to GitLab regarding this new ability?

It is still too early to determine feedback from our developer community and enterprise customers. However, we have noticed that the integration is working to help address three main pain points of the old manual mirroring process, including bidirectional mirroring, push mirroring and manual project service integration. To date, nobody from GitHub has reached out to GitLab regarding the new CI/CD integration.

It is also important to note that in early April, we announced a partnership with GKE (Google Kubernetes Engine), to allow developers to automate the setup and configuration of CI/CD and Kubernetes. The importance of ease of use of CI is one of the many factors that point to the growing popularity of this tool amongst community and enterprise developers.

Like most DZone readers, we spend our days focusing on building features and functionality for our projects. As part of working in Agile environments, the concept of planning is key - with an established backlog providing work for future sprints. Knowing that GitLab embraces the Agile development lifecycle, I wanted to ask if there are items on your backlog that you are willing to share - providing a glimpse into future planned releases.

Everything that we do at GitLab is open, including plans for future releases. On our Direction page, you can find details about company milestones, previous releases, get a sneak peek at future releases and check out our product vision.

For the next release, 10.8, we are working to release the following features: show incremental rollouts in deploy boards and view GitLab merge requests in associated JIRA issues in development panel, among other important features. It is important to note that the Direction page is always in draft, meaning some of the features listed might not ever be in GitLab, and that new features can be added to the Direction page at any time. 

Lastly, I wanted to follow up on the outage from February 1, 2017. A fix to resolve issues from hackers attacking the GitLab service resulting in some significant downtime for the service. I haven't noticed any downtime in the fourteen months since this outage, but I wanted to ask what has GitLab learned as a result of the situation?

Outages are unpredictable and can occur at any time, which is why it is important to establish a set of best practices/procedures when dealing with a major incident. The outage that occurred on GitLab in February of 2017 showed us that it’s tricky to only rely on the database itself when considering best practices for disaster recovery.As a result, we have been working to build better recovery procedures for the entire GitLab.com infrastructure, and not just the database; and to ensure there is ownership of these procedures. The incident also taught us as a company that it is best to be transparent when a major issue like an outage arises.

When we discovered the outage, we informed the entire GitLab community by publishing live updates on Twitter and the GitLab blog. Following the outage, we published a post-mortem blog that detailed the incident in its entirety. When handling a difficult situation like an outage, it is best for a company to remain open and honest with the affected users.

Thank you, so very much, for your time!

For those who are in a position to consider viable source code repository systems should certainly include GitLab in their short list to review - especially if DevOps will be part of the equation.

Have a really great day!