All the pipelines for the same microservice tend to look very similar.
#SAFE AUTO JOBS CODE#
For example, they don’t block infrastructure code changes from reaching production in the infrastructure pipeline. Application code changes that fail integration tests and block the application pipeline don’t affect other pipelines. Having multiple pipelines for the same microservice helps us deploy changes to production faster. Source changes are automatically rolled back if they cause any issues in production for the service (such as failures to parse a configuration file).Ī typical microservice might have an application code pipeline, an infrastructure pipeline, an OS patching pipeline, a configuration/feature flags pipeline, and an operator tools pipeline. For example, configuration values for a service that can change at runtime (like API rate limit increases and feature flags) are automatically deployed in a dedicated configuration pipeline. These sources are deployed in individual pipelines with the same safety mechanisms (like automatic rollback) that we use for deploying application code. The source code dependencies, such as libraries, programming languages, and parameters like AMI IDs, are automatically upgraded to the latest version at least weekly. All of these changes are version controlled in individual source code repositories.
They can validate and deploy changes to sources such as website static assets, tools, tests, infrastructure, configuration, and the application’s underlying operation system (OS).
Pipelines at Amazon automatically validate and safely deploy any type of source change to production, not only changes to application code. After I joined Amazon, I was excited to find out exactly how these “hands-off” automated deployments worked. Because the pipelines did this work for his team, most deployments weren’t actively watched by anyone.
When I asked how much of his day was spent carefully shepherding each of those deployments and watching logs and metrics for any impact as I had been doing, he told me usually none. The interviewer told me that changes were automatically deployed to production multiple times a day by continuous deployment pipelines. I read that Amazon practiced continuous deployment, so when I interviewed, I wanted to know how much time I would have to spend managing and watching deployments as a developer at Amazon. Then I frantically checked logs and metrics to see if I had broken anything after the deployment and needed to roll it back. For each fix that I released, I spent hours carefully rolling it out. When I interviewed for my job at Amazon, I made sure to ask one of the interviewers, “How often do you deploy to production?” At the time, I was working on a product that rolled out a major release once or twice a year, but sometimes I needed to release a small fix in between big releases.
0 kommentar(er)
