James Governor's Monkchips

Progressive Delivery at GitLab

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

I have been talking about Progressive Delivery for a while now – it’s an approach to deliver application and service functionality incrementally, to targeted user segments and production environments, limiting the blast radius, enabling experimentation with reduced risk. Progressive Delivery builds on the foundations laid by Continuous Delivery/Continuous Integration.

It’s gratifying to see engineers and vendors I respect taking the concept on, and GitLab is one of the latest to adopt the approach from a product management perspective. I recently spoke to Jason Lenny, Director of Product Management at GitLab, CI/CD about the company’s plans to package up some of its functionality with Progressive Delivery in mind. 

GitLab is an interesting case for a couple of key reasons:

  • It has a significant and fast growing enterprise footprint, notably with its CD product.
  • It develops software at high velocity, with a monthly release schedule and a strong bias to shipping, so you can watch improvements in real time. The company ships open source software and has a strong culture of corporate observability.

Lenny said:

“This idea about Progressive Delivery is nice because we have CD, Feature Flags, monorepo support, and Review Apps, so I was really excited about putting things together in that way.”

Lenny sees GitLab Review Apps, which enables live previews of feature branches, with a nicely integrated user interface for feedback, as differentiation in building a compelling Progressive Delivery offering.

Being GitLab Review Apps is a GitOps workflow but also has a neat Visual review feedback form, to collect user feedback and associated metadata.

Lenny said: 

“We can control the incremental rollout. Anyone could do this and achieve it but none of those products are going to be as well put together as GitLab in being the natural way of working. Drop into a developer environment for the first time, it’s already got feature flags, and can provision things for you, and monitor results. Nobody else can really compete with that.” 

But at this point monitoring and observability is one of the less well developed aspects of the GitLab suite. It has work to do there.

It’s still early in most enterprise digital transformation journeys. Progressive Delivery is of course not going to be applicable to everyone. 

“With 20 years of copying files around from server to server to get different jobs. You can’t get around enterprise apps, they have things like ETL… no proxying web service is going to fix that for you. The reality is that the vast majority of enterprises are in a transformation stage, and they have been for 10 years now. To get out of the legacy monoliths they built. But nobody wants to hear- how to get from one version to another. People are interested in how to get to 10.0 in their milestone list. If we can build this all into an app, and bundle it into how an app is created, it facilitates the transformation. Customers are familiar with the terms, they want a product that has a vision, that correlates with the vision of how things are going to be better in their org.”

Lenny finished with a strong statement of intent: 

“We do Progressive Delivery, it’s a legitimate story. I would love for GitLab to be the premier solution for trying this out.”  

It’s going to be really interesting to see how the product develops, and I look forward to seeing some case studies emerge to report. The most obvious end to end competitor is Microsoft, though plenty of other companies are now building Progressive Delivery tooling – such as CloudBees, Launch Darkly, Split, and Weaveworks.    

 

Disclosure: GitLab and Microsoft are both clients, but this is an independent report.

Related Posts – Towards Progressive Delivery, Progressive Delivery at SumoLogic

 

 

 

 

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *