Set a code freeze that an offshore team can actually follow

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Define the freeze by repository and risk

A code freeze should name the repositories, branches, and file areas it covers. A blanket instruction to stop all work is easy to announce and hard to follow because teams still need to fix urgent problems. Limit the freeze to the code that could change the release artifact. Write the list of paths and services so an engineer can check the rule without asking.

Tie the freeze to a specific release candidate or deployment window. State the commit or tag that the release will use and the time after which that reference will not move. If the release changes, revise the freeze notice rather than leaving an old rule in place. The team should know which build is protected, not just that a freeze exists.

Publish the window in both time zones

A freeze that ends at five o'clock in one office can end in the middle of another team's working day. Publish the start and end in the client time zone and the offshore time zone, with a UTC reference for the release system. Name the person who declares the freeze open and the person who confirms it is lifted. A shared calendar entry is not enough if the deploy pipeline uses a different clock.

Send the notice to the people who merge and release, not only to managers. Put the freeze at the top of the repository guide and the deployment channel. Ask the offshore lead to confirm that every engineer has seen the window and knows where exceptions are requested. Confirmation is a check, not a courtesy. A pinned message and a calendar hold work together.

Keep a narrow hotfix lane

A freeze without an exception path will be broken by the first production incident. Define a hotfix lane with a small scope, a named approver, and a required rollback note. The hotfix should touch only the files needed to restore the failed behavior. Require the same test evidence as a normal change, even when the window is short. Name the approver before the freeze starts.

Record each exception in the release log with the reason, approver, and time. After the release, review whether the hotfix could have waited. A pattern of frequent hotfixes means the freeze started too late or the release scope was too broad. Do not let the exception lane become the normal path. The log should stay visible to both teams after the release.

Freeze dependencies and configuration too

Dependency updates and configuration edits can change a release as much as application code. Include lockfiles, environment templates, feature-flag defaults, and build images in the freeze notice. A patch upgrade during the window can invalidate the tested artifact. The team should treat a lockfile change as a code change even when no source file moves. Include the lockfile and the build image in the notice.

Check the deployment platform for pending changes that could affect the release. A runtime update, a queue setting, or a certificate rotation may be outside the repository but inside the risk surface. Record the platform state at the start of the freeze. If a platform change is required, review it with the release owner before it happens. Capture that state in the freeze notice.

Verify the branch state before the window opens

Before the freeze takes effect, confirm that the protected branch builds from the intended commit. Run the test suite, record the artifact digest, and check that the release notes match the change list. Fix any unexplained difference before the window starts. A freeze that begins on an unverified branch only preserves uncertainty. Save the digest and test output beside the release tag.

Ask the offshore engineer to list the pull requests that are still open and the ones that will not make the release. Move unfinished work to a clearly labeled milestone so nobody assumes it shipped. Confirm that the branch protection rules still require review and passing checks. The freeze should reduce ambiguity, not create a second queue of hidden work.

Reopen with a written readiness check

Lift the freeze only after the release owner confirms the deployed artifact and the rollback state. Write the check as a short list: version, digest, smoke result, monitoring window, and open incidents. The offshore lead should sign the same list before normal work resumes. A verbal all-clear is too easy to mishear across time zones. Store the signed check with the release record.

Reopen the branch in stages if the release is still being watched. Allow low-risk documentation or test changes first, then application work after the monitoring window closes. Announce the change in the same channel as the freeze notice. The team should never have to guess whether the freeze is still active. State the exact date and time for each stage.

Review exceptions after the release

After the release, review every exception and every change that landed during the freeze. Ask whether the exception was necessary, whether the approval was clear, and whether the evidence was sufficient. Record one improvement to the freeze notice or the hotfix lane. The review should take minutes, not become another project. Invite both the offshore lead and the client owner.

Compare the planned release scope with what actually shipped. A difference may mean the freeze was declared before the branch was ready. Use the result to set the next freeze earlier or to narrow the release. The goal is a predictable window, not a perfect record of compliance. That difference is a planning signal, not proof of a compliance failure.

Frequently asked questions

Sources

1. NIST Secure Software Development Framework

   Release and change-control practices referenced here.

2. GitHub Docs, about protected branches

   Branch protection mechanics used in the readiness check.

3. CISA Secure by Design

   Guidance on controlled releases and accountable ownership.