A lot of planning is done before devs get the feature where I work. 1. Read through 'ticket' (feature/bug/whatever) 2. If its a change in an area I haven't wo

A lot of planning is done before devs get the feature where I work. 1. Read through 'ticket' (feature/bug/whatever) 2. If its a change in an area I haven't worked on, read through the code to figure out what it currently does. If its new think through the problem and ask any questions. Usually don't want to spend a lot of time on this - coding will generate questions/clarifications as you go (literally iterative). 3. Code, inclusive of tests. I occasionally write tests first if it is a well understood change/fix. If there are common libraries or cross cutting concerns in the change, run test suites of other projects against change. 4. Code review plus feedback changes. 5. Deploy to test env, wait for feedback from testing which includes QA and possibly other groups. 6. When testing is done, get approval for deploy and deploy to production. We have auto-builds after every push to certain branches with test results hitting chat so we all know if something went bad. We have the ops pieces in place to deploy whenever. Approvals are usually gotten in short order (an hour). Some apprehension exists with deploying on a Friday afternoon. Continuous delivery. If you're looking for detailed steps in step 3 above, it varies. Sometimes there are DB changes required, sometimes its an external integration, etc.