Usually wave1 is a small region and wave2 is the biggest region us-east-1, because you don't want to get to wave7 and only then discover the problem and rollback all the waves. If there is an issue you will most likely discover it in the biggest region. Everything that could go wrong will go wrong in us-east-1. The earlier you detect the problem the easier it is to rollback. The cost of the rollback increases the further your deployment progresses from wave1.
I would love to hear about the pace/cadence at which each iteration happens. For example for simple thing like CTA button background-color change. What is the time frame in which this thing get's into production and what is the developer workflow when his CL's are hanging for the review or CI. Does he waits? Does he take the next ticket? How fast is the CI/CD to see your change running in dev env? I mean... in simplest case... local WebPack gives you almost instant feedback. How "instant" it is at scale and workflow of AWS and the likes?
I like your presentation, to the point and with illustrations, makes it easy to follow. I wonder what tool are using for drawing, is this a tablet you mentioned?
Thanks for sharing! Shouldn’t the arrow when 1 box rolls back not point to gamma, but rather from fleet to 1-box since its rolling back to what the fleet has running, not to what gamma has?
Excellent video Daniel!..I would like ask you two quick questions: 1. In the scenario where all are released on the fleet in right way then what happen with the instances called Ibox, them continuing running or them are detroyed? 2. This presented approach is an available concept only for AWS environments or could be apply for others env?
14:50 question related to 1 Box Canary Deployment Strategy: Is it possible to route a specific user to that ~10% where the new feature is released in production, so the QA manual testers can validate the new feature?
Excellent video. Thanks. I have my CodeCommit repository but my code is not in a repo yet. My code is sitting in Lambda functions and Glue ETL functions etc. Do you have a recommended video for getting code into a CodeCommit Repo and start building my CI/CD pipeline?
Thanks for sharing the Amazon practices. I'm wondering how long is a single deploy (to a single region and worldwide)? are deploys sequenced? i.e. would you have to wait half a day because 3 other people got to merge their changes ahead of you and so you must wait for your turn to deploy?
Basically our teams have scheduled deployment, and they need to be approved. Sometimes there are changes that are not allowed to be deployed on prod and that is handle by feature flags. In one deployment process probably there multiple changes that people from the team were working at and are accumulated in Gamma.
Second time watching this video... I finally understand most of it now. This guy is genius.
Usually wave1 is a small region and wave2 is the biggest region us-east-1, because you don't want to get to wave7 and only then discover the problem and rollback all the waves. If there is an issue you will most likely discover it in the biggest region. Everything that could go wrong will go wrong in us-east-1. The earlier you detect the problem the easier it is to rollback. The cost of the rollback increases the further your deployment progresses from wave1.
I would love to hear about the pace/cadence at which each iteration happens. For example for simple thing like CTA button background-color change. What is the time frame in which this thing get's into production and what is the developer workflow when his CL's are hanging for the review or CI. Does he waits? Does he take the next ticket? How fast is the CI/CD to see your change running in dev env? I mean... in simplest case... local WebPack gives you almost instant feedback. How "instant" it is at scale and workflow of AWS and the likes?
I like your presentation, to the point and with illustrations, makes it easy to follow.
I wonder what tool are using for drawing, is this a tablet you mentioned?
Thanks for sharing! Shouldn’t the arrow when 1 box rolls back not point to gamma, but rather from fleet to 1-box since its rolling back to what the fleet has running, not to what gamma has?
Excellent video Daniel!..I would like ask you two quick questions: 1. In the scenario where all are released on the fleet in right way then what happen with the instances called Ibox, them continuing running or them are detroyed? 2. This presented approach is an available concept only for AWS environments or could be apply for others env?
14:50 question related to 1 Box Canary Deployment Strategy:
Is it possible to route a specific user to that ~10% where the new feature is released in production, so the QA manual testers can validate the new feature?
Great video. Thanks Daniel!
Excellent video. Thanks. I have my CodeCommit repository but my code is not in a repo yet. My code is sitting in Lambda functions and Glue ETL functions etc. Do you have a recommended video for getting code into a CodeCommit Repo and start building my CI/CD pipeline?
wonder if there is any project refrencing this pipeline or have to make one
Great thanks!
Thanks for sharing the Amazon practices. I'm wondering how long is a single deploy (to a single region and worldwide)? are deploys sequenced? i.e. would you have to wait half a day because 3 other people got to merge their changes ahead of you and so you must wait for your turn to deploy?
Basically our teams have scheduled deployment, and they need to be approved. Sometimes there are changes that are not allowed to be deployed on prod and that is handle by feature flags. In one deployment process probably there multiple changes that people from the team were working at and are accumulated in Gamma.
Just fyi, I work at amazon as well and we don’t really do the commit squashing thing. That’s probably a per-org thing.
That's bad. Do squash your commits 😄
In my team we squashed our commits. I think it is a great opportunity to divide your task from boards. And then work locally.