Plan Deployment

(Activity) for Tier: Release

PURPOSE

This activity outlines the minimal expectations for establishing agreements between the development and operations teams. Cooperation ensures developed products are scheduled and deployed to production according to plan.

Historically, deployments provided new features for the application. Modern software development displays an increased use in techniques such as feature toggle to deploy experiments to production and evaluate their effectiveness with a limited group of users. If the feature is effective, the feature becomes available to all users. In this model, releases are no longer tied to deployments.

WHEN

  • or in parallel with Plan a Release activity,
  • or if there are repeated significant variances in the Deployment Metrics (differences between planned and actual.)

ENTRY CRITERIA

(No entry criteria at this time.)

SUB-ACTIVITIES

  1. Create and Document Agreements

    • Create a written agreement between operations and development teams to support deployment of the product.

    • The agreement must include at least one date based deployment window.

    • Optional items you may wish to include:

      • Other important milestone dates (deployment to sandbox)
      • Roll back agreements or strategy
      • Post deployment Hot-fix limits or scheduling
      • Expected automation development agreements (who builds what scripts)
      • Emerging architectural change management agreements (deploying a new type of database)
      • Customer priority change notification agreements

    • Inform the Customer Support Manager of the planned deployment of the product

  2. Obtain Stakeholder Buy-in

    • Record the names of those who agree to the plan.

    • Record objections or concerns with the plan.

      Note

      Avoid attempts to list every theoretically possible risk/issue/concern which are not actionable.

      For example, it is possible that the SE may be out sick during the scheduled deployment window. Unless the need exists for a plan to mitigate this risk, avoid including it as a concern.

      For example, consider a new person in your role. There are some serious concerns that are widely known but not documented. In these cases, consider how information regarding these concerns is disseminated to the new member. If a clear path does not exist, consider documenting conversation starters or high-level information regarding the issue to help direct the new member in communicating with existing team members.

  3. Update Stakeholder Involvement Section within the Project Plan

    • If necessary, update the stakeholder involvement section of the project plan to reflect agreed upon communication channels.

EXIT CRITERIA

  • The plan has deployment window dates.
  • Stakeholders agree to the plan.
  • As needed updates to the stakeholder involvement section of the project plan

NEXT ACTIVITY

SEE ALSO

Process Guidance Version: 10.4