We took a multiple step approach to employ this practice:
- Set a predictable well-known deployment schedule;
- Adopt and aggressively use a modern SCM system (see previous post);
- Leverage existing defect / change management system;
- Establish great development environment that mirrors production; and
- Establish procedures to minimize code conflicts and management overhead.
As per below figure, we chose to go with a monthly deployment schedule. Key factors that played into this decision:
- Follow best practice - deploy early and often.
- Be respectful of user's time - exhausted from release one and have real jobs to do.
- Keep it simple - developers work in one environment / one branch at a time.
- Deliver product monthly - increase user satisfaction.
Monthly Deployment Schedule
14 Deploy production candidate to TEST
21 Deploy tested candidate to PROD
28 Finalize content of next production candidate
User Schedule
15-21
a) Test production candidate until ready for production use
b) Select areas of focus / critical items for next release
28 Review, update, and approve spec updates for next release
Developer Schedule
1-14 Code, test, and deploy assignments in DEV
15-21 Fast turn-around bug-fixes in TEST, and final updates to spec’s
22-28 Get new release assignments, draft spec updates
Field Notes: So far so good. We've completed two monthly cycles here. User satisfaction is way up. As the Deployment Manager, had to invest significant time to get our programmers skilled-up in Git and versed in our ever evolving procedures. But we're getting there, delivering code, and having fun.
Field Notes: So far so good. We've completed two monthly cycles here. User satisfaction is way up. As the Deployment Manager, had to invest significant time to get our programmers skilled-up in Git and versed in our ever evolving procedures. But we're getting there, delivering code, and having fun.
