Release and Patch Management

Release and patch management. This lesson is about controlling the path code and fixes take to production: through separated environments, and in the right order.

Here is the scene. A developer needed to fix a bug quickly, so they logged straight into production with the admin access they have always had, edited the live code, and moved on. It worked, this time. There was no separate test of the fix, no release record, and nothing stopping the next edit from taking the system down. The path from a developer’s keyboard to live was a single step.

The foundation is environment separation. First, development: where code is written and changed.

Second, test, and often a staging environment: where it is verified, against representative, not live, data, as Domain three insisted.

And third, production: the live system serving the business. Three environments, kept apart.

Keeping them separate does two things. It ensures only tested, authorised releases reach production, rather than half-finished code running against real data. And it enforces segregation of duties: the people who build changes are not the people who operate production. Release management is the controlled process that packages an approved, tested change and deploys it across that boundary.

Now patch management, and the exam’s key point: how patches are prioritised. Not by release order, not alphabetically, not by download size, but by risk and criticality. How severe is the vulnerability the patch fixes, and how exposed and how critical is the affected system.

So a critical flaw on an internet-facing, business-critical system is patched first; a low-severity issue on an isolated internal system can wait. This risk-based ranking directs limited effort where exposure is greatest, and it is the same appetite-and-magnitude thinking from Domain two, applied to patching.

And patches are still changes. So they go through change and release management: tested where practical before deployment, and applied through the controlled path. Even an urgent security patch for an actively exploited vulnerability follows the emergency change route, expedited, but authorised and recorded, rather than pushed straight to production untested and untracked.

Which brings us back to the developer. The permanent admin access to production is the flaw underneath the whole scene. Standing developer access to production lets changes reach live systems outside the release process, untested and unauthorised, and it collapses the segregation between building and operating.

So production access is restricted, and changes flow only through the controlled release path. Where developers genuinely need occasional production access to investigate, it is granted narrowly, temporarily, and logged, not held as a standing right that turns every quick fix into a shortcut past control.

So carry this away. Separate development, test and production so only tested code reaches live. Prioritise patches by risk, not by anything else. And developers with standing production access are both a release-management failure and a segregation-of-duties finding.