Deploying a package safely
A safe deployment takes the same package through each environment in turn, with configuration supplied separately for each one. Production needs approval, runs in an agreed window, is checked straight afterwards, and has a rollback plan: usually, deploy the previous version again.
Promotion through environments
Promotion means moving the *same* artifact, the same version with the same checksum, from one environment to the next. What changes between environments is configuration: database names, URLs, dataset prefixes, credentials. Keep configuration outside the package and supply it per environment, so that the package itself never needs rebuilding.
Gates before production
- Approval: a pipeline
inputstep, or a change record approved by the change board. - Change window: an agreed time when the business can accept a short risk, often evenings or weekends.
- Evidence: test results, the version and its checksum, attached to the change record.
Deployment strategies
| Strategy | How it works | Main benefit |
|---|---|---|
| All at once | Stop, replace, start | Simple, but users notice the outage |
| Rolling | Update servers a few at a time | No full outage |
| Blue-green | Run the new version beside the old one, then switch traffic over | Switching back is just switching traffic back |
| Canary | Send a small share of users to the new version first | Problems hit a few users, not everyone |
Check, then decide: keep or roll back
Straight after deploying, run smoke tests: a handful of quick checks that the main functions work, such as logging on, one enquiry and one update. Watch the error rates and logs for a while. If something is wrong, roll back, which usually means deploying the previous version again. That is only possible if the previous artifact is still stored and the deployment is automated.
Deploying to z/OS
On the mainframe, deploying usually means copying the load modules into the target load libraries, then making the running systems use them. CICS keeps programs in memory, so the new version is picked up with a NEWCOPY or PHASEIN of the program. Programs with static SQL need their Db2 packages bound. Tools such as IBM Wazi Deploy, IBM UrbanCode Deploy and Ansible automate these steps and record what was deployed where.
What is the usual way to roll back a bad deployment? (Answer in a few words.)
Show a hint
Think about the artifact you kept.
Show the solution
Deploy the previous (last good) version of the artifact again.
Common mistakes
Then production runs something nobody tested. Promote the artifact that passed testing.
A package that contains test database names must be rebuilt for production. Supply configuration per environment.
'We will fix it forward' at 2 a.m. is a gamble. Keep the previous version and know the command that redeploys it.
What you will see at work
- Change records usually ask for the version being deployed, the test evidence and the rollback plan. The pipeline can supply all three.
- After a production deployment, someone watches the dashboards for a set time before the change is closed.
- On z/OS, forgetting the CICS NEWCOPY is a classic reason why 'the fix is deployed but nothing changed'.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.