How is CI/CD changing because of AI, and what are sensible deployment practices more teams should be doing? Robert Erez is a CI/CD expert, and also my former teammate at Skype. Timestamps:
00:00 Intro 02:09 Canary deployments at Skype 05:01 Joining at Octopus Deploy 06:15 Continuous deployment 10:26 Why Kubernetes won 15:51 Kubernetes on-prem 18:50 How GitOps works 25:00 The uses and limitations of GitOps 31:04 The rise of platform teams 35:51 How AI is changing CI/CD 39:49 Progressive delivery explained 47:31 Rollbacks and roll-forwards 50:14 Feature flags 54:32 How development environments are evolving 57:40 Cloud development environments (CDEs) 1:03:45 Self-hosting CI/CD 1:09:25 Getting started with progressive delivery 1:11:15 Book recommendations
Brought to you by:
• @AntithesisHQ – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. https://antithesis.com/pragmatic
• @WorkOS – everything you need to make your app enterprise ready https://workos.com
• @turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. https://turbopuffer.com/pragmatic
Three interesting thoughts from Rob:
1. Roll forward, never backwards.
When a system has state – which typically means it uses databases – then doing a rollback can leave the code talking to a schema that’s no longer in sync. Rob’s advice is to not treat a failure in v2 as a trip back to v1, but rather as a push to v3 with the fix in it.
2. GitOps isn’t actually about Git.
None of the four pillars of GitOps – 1) declarative, 2) versioned and immutable, 3) pulled, not pushed, 4) continuously reconciled – require Git, although Git can work under these constraints. Yet, the term ‘GitOps’ has made the industry dogmatic about cramming everything into a repo – even things like secrets that absolutely shouldn’t be there!
3. There’s a trend of ephemeral environments replacing test/staging environments across the industry.
Companies used to have a few testers fighting over a handful of static test environments, but today, it’s trivial to spin up a full environment, per-feature branch, pre-merge. This is an “ephemeral” environment for evaluating that things work, which is then torn down once something is merged. It helps speed up the feedback process.
