So we started to get more disciplined in our approach, we started seeing the things that were going wrong, and we started to introduce more of the deployment automation, more of the configuration management infrastructure as code, better approaches to automated testing, and starting to formulate basic deployment pipelines out of those. There were about 200 people working on this agile project on three different continents… In those days it sounded really weird, because agile projects in those days were just small projects. Later on I worked on a project for a points-of-sale system when I worked for ThoughtWorks in the early 2000’s… And we were doing extreme programming at some scale at the time we thought that it was probably the biggest agile project in the world. So I remember me and a friend spending two days, stood up in a server room somewhere, trying to manually install the software… And I was thinking “There’s gotta be a better way of doing this…” We didn’t know what the configuration system was really, so that didn’t work very well. And the system wasn’t configured in the way that we expected. I had a kind of formative experience, several formative experiences… But one time I remember in the late ‘90s building some reasonably complex software for an insurance company, and we were supposed to deploy it by writing a manual script that somebody would then take over and execute. I’ll start off by admitting that I’m very old and I’ve been doing this for a long time… So mostly how I came up with this is by doing it wrong in lots of weird and interesting ways first, and finding out what didn’t work. I think you, Dave, had something to do with this, because around 2012 you published this book, you co-authored this book with Jez Humble, which was called “Continuous Delivery.” By the time they notice there’s a problem, you’ve fixed it, and it doesn’t exist. How do you learn if you don’t make mistakes? So don’t try to not make mistakes, try to make them so quickly and fix things so quickly that no one even notices. And even if you make mistakes, that’s okay. Like, why haven’t we been doing this all along? I mean, what else do you need just to get it out there for the users to tell you “Does it work, or doesn’t it work?” or “You’re missing this.” The quicker you can get to that point, the better off you are. There starts to be a shift in 2012/2013 there was an acceleration of just git pushing, and the code would get out there.
FTP used to be used a lot, rsync used to be a thing, getting thing out there… And something happened around 2010. I remember how difficult it used to be to get code into production. Wrap code in feature flags to get the safety to test new features and infrastructure in prod without impacting the wrong end users. Deploy code at any time, even if a feature isn’t ready to be released to your users. Get started for free their 30-day trial or try their forever-free tier.
Build and scale fast with CockroachCloud (CockroachDB hosted as a service) where a team of world-class SREs maintains and manages your database infrastructure, so you can focus less on ops and more on code. Try Teleport today in the cloud, self-hosted, or open source at Ĭockroach Labs – Scale fast, survive anything, thrive everywhere! CockroachDB is most highly evolved database on the planet. Engineers and security teams can unify access to SSH servers, Kubernetes clusters, web applications, and databases across all environments. Teleport – Teleport Access Plane lets you access any computing resource anywhere. Learn more at /changelog or email for a personal introduction and to ask questions about the Render platform. Render is built for modern applications and offers everything you need out-of-the-box.
Render – The Zero DevOps cloud that empowers you to ship faster than your competitors.
0 kommentar(er)
