Using Blueprints or mApps for Concurrent Development

Use the following workflows to accommodate multiple designers simultaneously working on system changes using Blueprints or mApps.

Use Blueprints for Concurrent Development

When you use Blueprints for concurrent development, you use two or more Blueprints to develop the functionality and then apply each Blueprint to the production environment.

To use Blueprints for concurrent development:

  1. Project Manager creates a rollout document. The document should be detailed and include the following information at the very least:
    • A list of stakeholders, including:
      • Business Object owners who are the sole developers assigned to work on a particular Business Object, including its Views (example: Portal View) and features (example: Dashboards, Widgets, One-Steps, etc.).
      • Feature owners who are the sole developers assigned to work on a particular feature (example: Calendar) that does not have an associated Business Object.
      • A gatekeeper who ensures that the Blueprint adheres to requirements and follows team standards (example: Naming conventions, design guidelines, etc.) before being published.
      • A product manager who is responsible for the scope and outcome of the project.
    • Required external connections (example: SCCM, Outlook, Active Directory, etc.).
    • Impacted CSM Services (example: Application Server, Automation Process Server, etc.).
    • System configurations that must be done outside the Blueprint. These might include changes to Security, the Scheduler, E-Mail Monitor, etc.
    • Test plans, including any user acceptance test requirements.
    • A backup and recovery plan.
  2. Create a development environment for by restoring the master development server to the current production environment. When creating this environment, consider the following:
    • Create one copy of the production environment and store it in a shared location.
    • You do not need to include Attachments in the file unless you are specifically testing their functionality.
    • Ensure that all impacted CSM Services (example: Application Server, Automation Process Service, etc.) are disabled. If you need to test E-mail Monitor functionality, make sure to configure the test e-mail account.
  3. Develop the functionality.
    1. Designers make individual copies of the master development database.
    2. Designers communicate which Business Objects and features they intend to work on.
    3. Designers develop the functionality using individual databases.
  4. Conduct internal testing on the first Blueprint:
    1. Reference the rollout document to ensure that:
      • The current Blueprint is intended to be published first.
      • The Blueprint includes all of the required system configurations.
    2. Publish the Blueprint using the master development environment.
    3. Test the Blueprint.
    4. Edit the Blueprint or create a new Blueprint based on test results.
    5. Repeat internal testing (steps a through d) until the gatekeeper approves the Blueprint.
    6. Update the rollout document. Make sure to include any additional system configurations that were done outside of the Blueprint.
  5. Conduct internal testing on the second Blueprint using the development environment that includes the first published Blueprint:
    1. Reference the rollout document to ensure that:
      • The current Blueprint is intended to be published second.
      • The Blueprint includes all of the required system configurations.
    2. Publish the Blueprint using the master development environment.
    3. Test the Blueprint.
    4. Edit the Blueprint or create a new Blueprint based on test results.
    5. Repeat internal testing (steps a through d) until the gatekeeper approves the Blueprint.
    6. Update the rollout document. Make sure to include any additional system configurations that were done outside of the Blueprint.
  6. Conduct internal testing on subsequent Blueprints by repeating the instructions in step five.
  7. Release the Blueprint into the production environment:
    1. Gatekeeper applies the first Blueprint while referencing the rollout document.
    2. Gatekeeper applies the second Blueprint while referencing the rollout document.
    3. Gatekeeper applies subsequent Blueprints while referencing the rollout document.
    4. Gatekeeper conducts a final review and publishes the Blueprints to the master development database.
    5. Quality Assurance Engineers complete regression testing.
    6. Publish the Blueprints in the production environment. The order in which the Blueprints are published is critical. Ensure that the Blueprints are published in the same order that they were applied to the master development database.
  8. Conduct a post-implementation review.

Use mApps for Concurrent Development

When you use mApp solutions for concurrent development, you have two options:
  • Use two or more Blueprints to develop the functionality and then create a mApp to apply the functionality into the production environment. (Process shown below.)
  • Use two or more mApps to develop the functionality and then apply each mApp to the production environment.

To use mApps for concurrent development:

  1. Project Manager creates a rollout document. The document should be detailed and include the following information at the very least:
    • A list of stakeholders, including:
      • Business Object owners who are the sole developers assigned to work on a particular Business Object, including its Views (example: Portal View) and features (example: Dashboards, Widgets, One-Steps, etc.).
      • Feature owners who are the sole developers assigned to work on a particular feature (example: Calendar) that does not have an associated Business Object.
      • A gatekeeper who ensures that the mApp adheres to requirements and follows team standards (example: Naming conventions, design guidelines, etc.) before being applied.
      • A product manager who is responsible for the scope and outcome of the project.
    • Required external connections (example: SCCM, Outlook, Active Directory, etc.).
    • Impacted Services (example: Application Server, Automation Process Server, etc.).
    • System configurations that must be done outside the Blueprint. These might include changes to Security, the Scheduler, E-Mail Monitor, etc.
    • Test plans, including any user acceptance test requirements.
    • A backup and recovery plan.
  2. Create a development environment for by restoring the master development server to the current production environment. When creating this environment, consider the following:
    • Create one copy of the production environment and store it in a shared location.
    • You do not need to include Attachments in the file unless you are specifically testing their functionality.
    • Ensure that all impacted CSM Services (example: Application Server, Cherwell Service Host, etc.) are disabled. If you need to test E-mail Monitor functionality, make sure to configure the test e-mail account.
  3. Develop the functionality.
    1. Designers make individual copies of the master development database.
    2. Designers communicate which Business Objects and features they intend to work on.
    3. Designers develop the functionality using individual databases.
  4. Conduct internal testing on the first Blueprint:
    1. Reference the rollout document to ensure that:
      • The current Blueprint is intended to be published first.
      • The Blueprint includes all of the required system configurations.
    2. Publish the Blueprint using the master development environment.
    3. Test the Blueprint.
    4. Edit the Blueprint or create a new Blueprint based on test results.
    5. Repeat internal testing (steps a through d) until the gatekeeper approves the Blueprint.
    6. Update the rollout document. Make sure to include any additional system configurations that were done outside of the Blueprint.
  5. Conduct internal testing on the second Blueprint using the development environment that includes the first published Blueprint:
    1. Reference the rollout document to ensure that:
      • The current Blueprint is intended to be published second.
      • The Blueprint includes all of the required system configurations.
    2. Publish the Blueprint using the master development environment.
    3. Test the Blueprint.
    4. Edit the Blueprint or create a new Blueprint based on test results.
    5. Repeat internal testing (steps a through d) until the gatekeeper approves the Blueprint.
    6. Update the rollout document. Make sure to include any additional system configurations that were done outside of the Blueprint.
  6. Conduct internal testing on subsequent Blueprints by repeating the instructions in step five.
  7. Create a mApp based on the approved system configurations included in the Blueprints:
    1. Gatekeeper applies the first Blueprint while referencing the rollout document.
    2. Gatekeeper applies the second Blueprint while referencing the rollout document.
    3. Gatekeeper applies subsequent Blueprints while referencing the rollout document.
    4. Gatekeeper creates a backup of the master development server that includes all of the Blueprints.
    5. Gatekeeper conducts a final review and creates a mApp based on the approved system configurations included in the Blueprints.
  8. Conduct testing on the mApp:
    1. Apply the mApp while referencing the rollout document.
    2. Test the mApp while referencing project requirements.
    3. Edit the mApp or create a new mApp based on test results.
    4. Repeat testing (steps a through c) until the gatekeeper approves the mApp.
    5. Update the rollout document.
  9. Release the mApp into the production environment:
    1. Gatekeeper conducts a final review and applies the mApp to the master development database.
    2. Quality Assurance Engineers complete regression testing.
    3. Publish the mApp to the production environment.