| <?xml version="1.0" encoding="UTF-8"?> |
| <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1"> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-PSYszO1VnJHhh76PS4GsoQ" name="01_02_install_validate_infrastructure,_qWKsoPd3EeCFmpfCmMPILg" guid="-PSYszO1VnJHhh76PS4GsoQ"> |
| <refinedDescription><p>
 |
| A release package cannot be deployed to production if the environmental infrastructure within which the release will be
 |
| run is not sufficiently built or tested. Whether the release is deployed as a "push" (where the application is deployed
 |
| from a central point and proactively delivered to target locations) or a "pull" (where the application is made
 |
| available at central point and pulled by a user at a time of their choosing), the infrastructure needed to support the
 |
| application must be considered and implemented.
 |
| </p>
 |
| <p>
 |
| Some key aspects of installing and/or validating the desired infrastructure:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Identify the requirements and components of the environment configuration
 |
| </li>
 |
| <li>
 |
| Determine the lead times required to establish the infrastructure environments
 |
| </li>
 |
| <li>
 |
| Procure and install the infrastructure components that are not yet available
 |
| </li>
 |
| <li>
 |
| Test the newly installed infrastructure components
 |
| </li>
 |
| <li>
 |
| Test the integration of newly installed components with the rest of the environmental configuration
 |
| </li>
 |
| <li>
 |
| Validate other aspects of the infrastructure including: 
 |
| <ul>
 |
| <li>
 |
| Security components and their integration
 |
| </li>
 |
| <li>
 |
| Database connectivity and security
 |
| </li>
 |
| <li>
 |
| License management, as appropriate
 |
| </li>
 |
| <li>
 |
| Configuration management, in terms of configuration items (CIs)
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-7ZImjs9oa1GUIfRAA-aZ7A" name="01_04_create_update_backout_plan,_qWKsovd3EeCFmpfCmMPILg" guid="-7ZImjs9oa1GUIfRAA-aZ7A"> |
| <refinedDescription>A rollback might be needed for a variety of reasons, including corruption of the production code base, inoperable
 |
| components, an unplanned undesirable effect of the release on other production systems, an unhappy Customer, etc.
 |
| The&nbsp;Development Team should provide the production support organization with a specific plan and decision criteria
 |
| made available to them to avoid or minimize service interruptions.</refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-LyV_ZO1Np5hR4jCzxdP8lg" name="01_05_develop_release_communications,_qWKso_d3EeCFmpfCmMPILg" guid="-LyV_ZO1Np5hR4jCzxdP8lg"> |
| <refinedDescription><p>
 |
| When a release is pushed to production, all the Stakeholders of that product should be notified that the event has
 |
| happened and what the release means to each of the Stakeholders. Often, the output of this task does not need to be
 |
| created from scratch; for products that plan multiple releases, just updating the communique details for each release
 |
| might be enough. However, if any of the Stakeholder groups change, or there is a significant difference in the product
 |
| distribution, more significant content might need to be developed.
 |
| </p>
 |
| <p>
 |
| In any case, communicating effectively to the End User community is important. A Development Team can develop high quality
 |
| software, but if messaging to the Stakeholders is conducted poorly or not at all, the End User experience might be
 |
| degraded. By simply answering the questions "who, what, when, where, why, and how" in a format appropriate for each
 |
| Stakeholder group, a product release can become a more satisfying experience for all those involved.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-7MHd2XgrDNoZemDYzKTd4Q" name="deployment_engineer,_qWLTsPd3EeCFmpfCmMPILg" guid="-7MHd2XgrDNoZemDYzKTd4Q"> |
| <refinedDescription><p>
 |
| A Deployment Engineer&nbsp;assists the&nbsp;Deployment Manager who is responsible to senior management for the
 |
| successful deployment of integrated or stand-alone releases into production. This team member role is critical to the
 |
| safety of the production environment and helps prevent the introduction of bad or untested code into production&nbsp;on
 |
| which the organization's internal and external Customers depend. Deployment Engineers support the Deployment Manager in
 |
| the mission to continually lead, facilitate, and coordinate synchronized releases by using the program to
 |
| maximize value delivered to their program Customers.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-4IwCugarUHSvovyhSVaC8w" name="developer,_qWLTsvd3EeCFmpfCmMPILg" guid="-4IwCugarUHSvovyhSVaC8w"/> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-x7jM0IZFOAC4CvMUpzlfKA" name="deployment_plan,_qWLTtPd3EeCFmpfCmMPILg" guid="-x7jM0IZFOAC4CvMUpzlfKA"> |
| <refinedDescription><p>
 |
| The Deployment Plan should contain the unique instructions for deploying a particular version of a product. By "unique
 |
| instructions" we mean those things that are not part of a Deployment Engineer's normal procedures. Rather, they often
 |
| are specific procedures and timing constraints that a Deployment Engineer should be aware of as they are rolling out a
 |
| particular release.
 |
| </p>
 |
| <p>
 |
| While&nbsp;a draft version of the&nbsp;Deployment Plan is typically developed by a Development Team, the Deployment
 |
| Engineer is responsible for its contents and existence.&nbsp;A Deployment Plan&nbsp;normally consists of the following
 |
| sections:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The scope of the release and a general overview of the capabilities to be deployed
 |
| </li>
 |
| <li>
 |
| The timing and dependencies for deploying components to various nodes
 |
| </li>
 |
| <li>
 |
| The risks or issues associated with the release based on a risk assessment
 |
| </li>
 |
| <li>
 |
| The customer organization, Stakeholders, and End User community that will be impacted by the release
 |
| </li>
 |
| <li>
 |
| The person or persons who have the authority to approve the release as "ready for production"
 |
| </li>
 |
| <li>
 |
| The Development Team members responsible for delivering the release package to the Deployment Manager, along with
 |
| contact information
 |
| </li>
 |
| <li>
 |
| The approach for transitioning the release package to the Deployment Engineer, including appropriate communications
 |
| protocols and escalation procedures
 |
| </li>
 |
| <li>
 |
| The success criteria for this deployment; in other words, how will the Deployment Engineer know that the release is
 |
| successful so it can report success
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-SymlacROUb5bShbsw846gw" name="release_controls,_qWLTtvd3EeCFmpfCmMPILg" guid="-SymlacROUb5bShbsw846gw"> |
| <refinedDescription><p>
 |
| Some common release controls are:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| A release or deployment plan must be documented and reviewed with the Deployment Manager (or the release
 |
| organization). This plan must address how risks, issues, or code deviations are to be handled during the key
 |
| timeframe leading up to the actual release
 |
| </li>
 |
| <li>
 |
| The components of each release package must be defined, integrated, and compatible with one another
 |
| </li>
 |
| <li>
 |
| The integrity of each release package must be verified and maintained
 |
| </li>
 |
| <li>
 |
| References to the configuration items (CIs) that the release package represents, if applicable
 |
| </li>
 |
| <li>
 |
| The customer for which the application is being developed must approve the release, indicating that the user
 |
| community (or a specific subset) is ready to receive and use the requisite capabilities of the release
 |
| </li>
 |
| <li>
 |
| Each release package must be capable of being backed out of production without negatively impacting the remaining
 |
| production environment
 |
| </li>
 |
| <li>
 |
| The contents of each release package must be transferred to operations and support staff with sufficient
 |
| documentation and knowledge transfer so that those organizations can effectively support the released capabilities
 |
| in production
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-eIsGLOhYKE9d9gScztUFiQ" name="infrastructure,_qWLTuPd3EeCFmpfCmMPILg" guid="-eIsGLOhYKE9d9gScztUFiQ"> |
| <refinedDescription><p>
 |
| Infrastructure normally is defined as anything that supports the flow and processing of information in an organization.
 |
| The infrastructure needed to support a release package normally includes:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Software, including: 
 |
| <ul>
 |
| <li>
 |
| Operating systems and applications for servers and clients
 |
| </li>
 |
| <li>
 |
| Desktop applications
 |
| </li>
 |
| <li>
 |
| Middleware
 |
| </li>
 |
| <li>
 |
| Protocols
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| Hardware
 |
| </li>
 |
| <li>
 |
| Networks, including: 
 |
| <ul>
 |
| <li>
 |
| Routers
 |
| </li>
 |
| <li>
 |
| Aggregators
 |
| </li>
 |
| <li>
 |
| Repeaters
 |
| </li>
 |
| <li>
 |
| Other transmission media devices that control movement of data and signals
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| Facilities
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-IhfK-TBRtHklzkKVrccUvw" name="backout_plan,_qWLTuvd3EeCFmpfCmMPILg" guid="-IhfK-TBRtHklzkKVrccUvw"> |
| <refinedDescription><p>
 |
| While someone on the Development Team normally authors a draft version of the Backout Plan, the Deployment Engineer is
 |
| ultimately responsible for its contents and existence. A Backout Plan typically answers the following questions:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Under what circumstances will a rollback be required? Or conversely, under what circumstances will the deployment
 |
| be considered a success?
 |
| </li>
 |
| <li>
 |
| What is the time period within which a rollback can take place?
 |
| </li>
 |
| <li>
 |
| Which authorizing agent will make the decision to revert?
 |
| </li>
 |
| <li>
 |
| Who will perform the rollback and how soon after the decision has been made will the rollback be performed?
 |
| </li>
 |
| <li>
 |
| What procedures (manual and automated) will be followed to execute the rollback?
 |
| </li>
 |
| <li>
 |
| What other contingency measures or available workarounds should be considered?
 |
| </li>
 |
| <li>
 |
| What is the expected time required to perform a reversion?
 |
| </li>
 |
| <li>
 |
| What are the communication procedures required in the event of a backout?
 |
| </li>
 |
| <li>
 |
| Has the Backout Plan been successfully tested?
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-grT7fq-8SP3IEHJFjdrz-A" name="release_communications,_qWLTvPd3EeCFmpfCmMPILg" guid="-grT7fq-8SP3IEHJFjdrz-A"> |
| <refinedDescription><p>
 |
| Sometimes, depending on the product user base, separate communiques might need to be prepared for each Stakeholder
 |
| group. In that case, this artifact should specify the different groups to which communications are directed, the method
 |
| of communication (e.g., email, text or pager message, bulletin, newsletter, phone message, etc.). All communiques
 |
| should be prepared in advance so that it is a matter of disseminating information when the release to production has
 |
| been determined to be successful.
 |
| </p>
 |
| <p>
 |
| Also included in this artifact is a listing of the responsible parties who will execute the communications when a
 |
| successful release has been declared (normally the Deployment Engineer), as well as the timing and dependencies of the
 |
| communiques.
 |
| </p>
 |
| <p>
 |
| While there is no prescribed format for the Release Communications artifact, each communique should indicate the
 |
| preferred delivery mechanisms (e.g., beeper notification, telephone calls, a posting to an internal release website,
 |
| live or pre-recorded presentations by senior management, etc.) and generally answer the following questions:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Who are the parties (Stakeholders) that are interested in knowing that a release to production has taken place?
 |
| </li>
 |
| <li>
 |
| What specifically (features, functions, components) has been placed into production?
 |
| </li>
 |
| <li>
 |
| Why is this release valuable to Stakeholders and what business purpose does it serve?
 |
| </li>
 |
| <li>
 |
| Where is the product available (on which platforms, geographical locations, business units, etc.)?
 |
| </li>
 |
| <li>
 |
| How can the Stakeholders access the system and under what circumstances?
 |
| </li>
 |
| <li>
 |
| When was the product released (or when will it be released if the release date is in the future)?
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-cvDLlTlRc9rDk8NGoWkvcg" name="release,_qWNv8Pd3EeCFmpfCmMPILg" guid="-cvDLlTlRc9rDk8NGoWkvcg"> |
| <refinedDescription><p>
 |
| A Release consists of integrated, compiled code that runs cleanly, independently, and in its entirety. This is an
 |
| important rule because in order to be released or even "potentially shippable," a Release increment must be able to
 |
| stand on its own, otherwise it is not shippable. Releases&nbsp;can be created at either the program or team level.
 |
| </p>
 |
| <p>
 |
| There are three potential uses for a Release:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>It is not used outside of the program:</strong> It has been produced to minimize risks linked to technology
 |
| and a program's capability to integrate components and to produce a Build. This situation usually happens at the
 |
| beginning of a new product lifecycle.
 |
| </li>
 |
| <li>
 |
| <strong>It is used by Beta Customers and the Program Manager:</strong> It allows End Users to test it in a Beta
 |
| test environment, which provides immediate feedback and reduces risks associated with user interface ergonomics.
 |
| Customer feedback will influence the Program Backlog for later consideration.
 |
| </li>
 |
| <li>
 |
| <strong>It is deployed or shipped and used by End Users:</strong> This result provides immediate value to the End
 |
| Users.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| In many organizations, a program Release typically is timeboxed to 2 to 3 months of development effort and 2 to 4 weeks
 |
| of hardening which results in a scheduled release approximately every 90 days. Releases for individual Development
 |
| Teams usually occur more often than those for programs, but there are no hard and fast rules regarding how often
 |
| releases should be scheduled. The only requirement is that working software should be delivered "frequently" by both
 |
| Development Teams and programs. Although the example timeframe described above is arbitrary, empirical evidence
 |
| suggests it is about right for most companies and fits nicely into quarterly planning cycles.
 |
| </p>
 |
| <p>
 |
| Each Release has a set of release objectives and a projected delivery date; it also has a planned number of Sprint/Iterations.
 |
| For example, a brief description of a release might be: "The goal of Release 2 is to provide B2B scheduling capability
 |
| for the Ordering and Logistics Department. The Release is targeted for June 31 and will consist of five 2-week Feature
 |
| Development Sprint/Iterations and&nbsp;one 2-week Release Sprint/Iteration."
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-TIDq6m5AxfWlAJfJCiHN7g" name="01_01_review_conform_to_release_controls,_1TCC0Pd3EeCFmpfCmMPILg" guid="-TIDq6m5AxfWlAJfJCiHN7g"> |
| <refinedDescription><p>
 |
| Release controls describe the minimum number of requirements that a software package must adhere to before being
 |
| released into production. This is especially important if a Development Team is new or emerging, because they might not be
 |
| aware of the great responsibilities a Deployment Manager has. In fact, a Deployment Manager is responsible to senior
 |
| management for ensuring that nothing is placed into production that does not conform to the rigid controls designed to
 |
| protect the IT organization's ability to successfully deliver IT services to internal and external Customers.
 |
| </p>
 |
| <p>
 |
| Release controls typically consist of:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Release or deployment plan
 |
| </li>
 |
| <li>
 |
| Backout plan
 |
| </li>
 |
| <li>
 |
| Release component definitions
 |
| </li>
 |
| <li>
 |
| Release package integrity verification
 |
| </li>
 |
| <li>
 |
| References to configuration items (CIs)
 |
| </li>
 |
| <li>
 |
| Customer approval
 |
| </li>
 |
| <li>
 |
| Ready for transfer to operations and support staff
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-eZJOOlVLjwqJ6USAOlOsJQ" name="prepare_for_release,_muQKwfd3EeCFmpfCmMPILg" guid="-eZJOOlVLjwqJ6USAOlOsJQ"/> |
| </xmi:XMI> |
