Change Release Protocol
Abhishek Srivastava
Abstract
This is a set of protocols for releasing the changes or new feature to staging and production. This in being introduced so as the developer does not skip any critical step required during the whole release process. Any critical step if is missed could lead to incidents in production environment.
Steps
Merge checklist Staging
Merge checklist Staging
Regen pb.go from shared-proto master branch
Create Gitlab PR for config change on Staging
Merge Gitlab PR for Staging
Run Migration Scripts if any on Staging
Test in local
Test in feature env:
Test Party
Merge checklist Production
Merge checklist Production
Run Migration Scripts if any on Production
Create Gitlab PR for config change on Staging
Merge Gitlab PR for Staging
Merge shared-proto change (if applicable)
Starting the Jenkins Pipeline
Starting the Jenkins Pipeline. Cutoff 3pm unless absolutely necessary/hot-fix
Announce on #backend-release channel
Check the result of QA test suite run on #qa-backend-releases slack channel
If any failures then check with the QA engineers
Get a go ahead from QA engineers to proceed in case of failures
Make sure config changes done
Make sure migration done if required
Proceed to Canary
Validate Changes on Canary
Validate Changes on Canary
Check logs on Canary Server
cat /tmp/carousell-stdout.log|grep -o -E -i ".*panic.*"|wc -l
Update the PR Template
Check for errors related to your grpc method
tail -100f /tmp/carousell-stdout.log|grep -E -i "\"method\":\".*<your_grpc_method_name>.*
Verify Changes on Canary if possible using port-forwarding
Check Grafana Dashboards for Hystrix and GRPC for error rates on New Canary pod
Wait for another 1 hour at least for baking the changes in Canary [Mandatory]
Check Grafana Dashboards for Hystrix and GRPC for error rates on New Canary Pod
If all good, proceed for all server roll-out
Verify Changes by completing the whole new flow on app/web to see all good with new feature/ old feature
Attach Screenshots from test on production