These are the things I add in when adding in a new usecase to a codename:
- Expansion of the acceptance criteria into small steps.
- Any clarifications to what we are making
- Anything I don't understand yet so i can chase up someone about it later
- As I read through the code I write up possible refactoring opertunties. (I find this a lot better than adding todos as you can skim though the list closer to the end and address things that matter most first. Often the code that seems silly at first has a decent reason to be that way with the full context knowen)
All of this helps me pull the right threads without having to switch context throughout the day
If you make your application stateless and have it in a container then there are many managed services out there that can do this for you. For example, in AWS there is fargate and EKS.
Their deployment UI looks nice but this feels like they made their own wheel here in order to keep their In-place upgrade method over something such immutable infrastructure using pre-existing deployment systems.
I wonder if this was ruled out for some reason or perhaps for a large company with people dedicated to deploying this doesn't matter. One example, as they are on AWS autoscaling groups with prebuilt AMI's could have been used to roll new machines instead of copying files to the server.