DevOps en AWS, acelarando el desarrollo de software con Developer Tools

Notas del editor

• #18: - when you're working with a monolithic app, you have many developers all pushing changes through a shared release pipeline - this causes frictions at many points of the lifecycle - upfront during development, engineers need to coordinate their changes to make sure they're not making changes that will break someone else's code - if you want to upgrade a shared library to take advantage of a new feature, you need to convince everyone else to upgrade at the same time – good luck with that - and if you want to quickly push an important fix for your feature, you still need to merge it in with everyone else's in process changes - this leads to "merge Fridays", or worse yet "merge weeks", where all the developers have to compile their changes and resolve any conflicts for the next release - even after development, you also face overhead when you're pushing the changes through the delivery pipeline - you need to re-build the entire app, run all of the test suites to make sure there are no regressions, and re-deploy the entire app - to give you an idea of this overhead, Amazon had a central team whose sole job it was to deploy this monolithic app into production - even if you're just making a one-line change in a tiny piece of code you own, you still need to go through this heavyweight process and wait to catch the next train leaving the station - for a fast growth company trying to innovate and compete, this overhead and sluggishness was unacceptable - the monolith became too big to scale efficiently so we made a couple of big changes - one was architectural, and the other was organizational
• #20: .
• #28: - one of the first primitives to emerge was Apollo, a name that we clearly borrowed from Nasa - Apollo is the deployment engine for Amazon, everything from the retail site to AWS services - it's how we roll out software changes across our servers - we first launched Apollo over a dozen years ago - in that time we've been continually learning about how to manage deployments and baking that knowledge back into the service - one capability was zero downtime deployments - there's no way we would allow taking the retail site down just to push a software change - Apollo supports rolling out a software change without taking down an application - we also can't let a deployment bug take down the app, so Apollo tracks deployment health and stops bad deployments
• #29: - with these new tools, we completed the puzzle - the teams were decoupled and they had the tools necessary to efficiently release on their own