While spending time relaxing on a southeastern beach in the United States over spring break, I was able to interview Job van der Voort, the vice-president of product at GitLab, Inc. During the interview, Job provided an update on what's new with GitLab 9.0 and spent time answering a series of questions that I prepared for him prior to our conversation.
John: I have been a fan of GitLab for a short time now, utilizing the GitLab service for a few of my personal repositories. I am quite impressed with what GitLab offers out of the box with the free service. So, what's new at GitLab?
Job: That's great to hear, John. Thank you for your kind words. I will give you a brief overview on what we did with GitLab 9.0.
At a high level, the idea behind GitLab is the ability to move from the idea to production:
idea - creation and documentation of the idea within the issue tracker inside GitLab
building and testing the code using GitLab as the repository
deploying the code via the pipeline process
With GitLab 9.0, this flow becomes a single experience for the development team housed within the GitLab ecosystem. When an idea is tracked by an issue, GitLab allows insight into where that issue has evolved (development, test, staging, deployment).
That's interesting, but what about after the code is deployed into production?
With GitLab 9.0, we have added environment monitoring—which allows you to immediately have insight into the performance of that machine/container—currently supporting Kubernetes environments.
This means that we no longer simply go from idea to production. Now, we go from idea to monitoring to back again, since the monitoring provides feedback into new ideas.
So, this can include application data and business metrics as well?
Environment monitoring is our first step of introducing monitoring, with plans to include application data and business metrics on our roadmap, as well. Imagine, being able to see the impact from a change by locating the merge request that introduced the functionality and reviewing the results. Very powerful idea.
In a world where one request can spawn multiple microservices, what does GitLab have to offer in order to support the ability to trace a given request through its lifecycle?
In one of the next releases, you can have custom metrics. This will allow you to say, "on the face of this request, this is what I want to show," which will leverage Prometheus (included in our ecosystem and is turned on by default).
Right now, you can already start sending metrics to Prometheus of any kind. We are working on the custom part of integrating your messages into the system.
Are there any items that you would consider a "game changer" in the 9.0 release?
Subgroups is something we believe will be a game changer. The idea is very simple, but no one has introduced the functionality in the space we are in. Basically, this is the idea of creating nested groups up to 20 levels deep. Building upon groups within projects (which was in place before), groups can contain subgroups pulling from Active Directory or LDAP. The potentials of using subgroups are endless, but one area where we saw a huge improvement is with the Android repository—one of the more complex repositories on GitLab.
That is a game changer, especially based upon my review of the current competitors in your market space. In fact, I was working with a client recently who migrated to another git-based solution and we quickly realized that the lack of folders at the organization level placed the hundreds of repositories in the same list—nearly impossible to navigate.
This is exactly what we set out to solve with subgroups... to do exactly what you are talking about. You are able to create a group and have repositories at that level. Or, you can have deeper nested groups. The concept is very much the same as the folder—all the power we gave you to manage people, to manage integrations, and to manage projects will also exist across and into the hierarchy.
As I noted before, the possibilities are endless and we are excited to hear how customers are utilizing this power functionality.
What else is shipping with GitLab 9.0?
Deployments have been part of GitLab for some time now. We realized that our customers are not deploying to a single machine. Nowadays, they are deploying many different containers. In GitLab 9.0 Enterprise Edition, we have a way to visualize this using deploy boards. With this functionality, you can see how your deploys are progressing across multiple containers.
In the first iteration, we are only supporting Kubernetes, but we have plans to include additional options in the future. We are also planning to include canary deploys in the future as well.
Do you have any updates with the Issue Tracker?
We have added a number of new features with GitLab 9.0:
the ability to export issues
the issue boards can be used for development teams to use as a sprint tool
issues can now be re-ordered
issues are auto-closed when dragged to the Done swim lane
We are trying to create a tool that has a low threshold to use, which is included in the base GitLab product.
What about the ability to assign an issue to multiple individuals? In my personal usage of ALM tools, this is one aspect that seems to be missing, causing duplicate efforts (sub-tasks, cloned issues/stories, etc.) with the options available to development teams today.
Great question and an interesting story. For a long time, we resisted doing this so that a single person is responsible for a single thing. We found that, as our own teams grew, we realized the need for this ability. We are now at that point where we need this functionality ourselves. I am happy to announce that we are in the final stages of adding this functionality, targeting for the April or May release we have planned.
Because we are open source, we have a large group of developers contributing their free time to assist with GitLab development. We feel that there has to be a way to thank people who really put a lot of effort into their contributions. We look at each contribution to see who we should reward for their hard work. Every month the choice is never easy, but it is something we truly enjoy doing.
Jacopo found something that seemed obvious after the fact, but was something no one had thought of doing before. In fact, as soon as we saw his idea and his wonderful work of implementing the idea, we all concluded that he would be our next MVP.
My last question is to talk about the GitLab outage that occurred earlier this year. I even wrote an article about it on DZone.com. What changes have taken place since the outage?
The big problem was that a team member executed a command against the wrong environment. We even had five backups in place... unfortunately, none of them worked. However, we were able to recover with only losing a few hours of data and not impacting our enterprise customers. We realized this was due to an issue with process more than anything else which validated the backups are happening and are usable. We feel very good about our ability to recover in the event of a similar outage going forward, regularly checking now.
GitLab 9.0 introduces more features and functionality to their service offering, making the process of going from idea to not only production, but also application monitoring, a reality. Not noted during the interview text, Job talked about the performance improvements that continue to occur with each release which should be noticeable in the larger repository instances. More information about GitLab 9.0 can be found here.
The current state and roadmap for GitLab certainly paints a strong picture for those seeking a cloud or on-premises solution for git-based repositories. I have been quite pleased, personally, with the usage of GitLab and look forward to the features Job and his team have planned for the coming releases.
I feel fortunate to have had the opportunity to spend time with Job van der Voort, learning more about the GitLab service.
Have a really great day!