Evolution of deployment tooling @ Chronosphere
summary
When the company is 1.5 years old it builds its own deployment system and after 2.5 years it runs in production: a CLI calls a Deployer service which kicks off Temporal workflows that orchestrate Kubernetes operations and custom m3db operators, add health checks, automated rollbacks and deploy freezes, and surface status in a React UI instead of five scattered tools. It removes wide kube creds, scales from a few tenants to dozens, but exposes visibility and dependency (Slack) lessons.
AI-written summary · about
chapters (20)
- 0:00Deployment tooling evolution
- 1:26Why Chronosphere built own system
- 3:53Early deployment process limits
- 8:02Requirements for perfect system
- 9:47Choosing Temporal workflow
- 11:54Redesigning user flow
- 13:41Impact on engineers
- 16:14First Deployer UI
- 18:21Streamlining UI confirmation
- 19:44Deployment freezes for safety
- 21:29Automating release pipeline
- 22:53Other improvements challenges
- 23:36Lessons on user needs
- 25:20Visibility in failures
- 26:03Reusable workflows
- 27:04Managing infra dependencies
- 28:07Building vs buying verdict
- 29:51User feedback for improvement
- 31:59Future of deployment tooling
- 32:51Q&A
related talks
35mKubernetes journey
31mContinuous Delivery Lessons Learned Through Hypergrowth
44mEvolving Dev and Ops with Kubernetes: Enterprise Adoption for Security, Speed, and Ease
17mDeployments We Can Believe In
38mScaling Kubernetes Deployments Across +15'000 Namespaces
34mEnabling a Continuous Deployment Mindset
33mBlueprints of Innovation: Engineering Paved Paths for a User-friendly Developer Platform
35mBuild fault tolerant, distributed apps with Kubernetes and Temporal