Managing configuration of applications, topology, and infrastructure
This topic explains the general procedure you might use to define and configure the building blocks for your release process, including the environments that support your release life cycle, applications supporting the release deployment, and finally, the routes and policies that enable you to coordinate the release workflow.
This topic includes the following sections and use cases:
Before you begin
- Plan your release life cycle. Consider the following stages:
- Development
- Quality assurance (QA)
- User acceptance testing
- Deployment to production
- Plan the environment needed for successful release deployment, including hardware, software, and network components.
- Ensure the integration of all external systems that you are planning to use such as a build server, bug tracking system, test management system, and so on.
- Based on your release life cycle model, create plan templates for your continuous integration, deployment, and release plan.
- Plan roles for your project team members. For example:
- Release manager—Schedules, coordinates, and manages releases, including application updates, patches, and security improvements.
- Environment manager—Manages processes for an application within a specific environment, including strategies for moving the application to another environment.
- Test engineer—Uses requests to test whether the product meets applicable specifications.
- Plan your product support and updating, including the continuous building, deploying, and updating of software and environments.
High-level steps for managing configuration of applications, topology, and infrastructure
- Develop the release plan template with the necessary stages that match your release life cycle. For example, you might have the following stages: development > performance testing > regression testing > pre-release testing > user acceptance > deployment to production.
- Create the infrastructure for every release stage. You might have several servers for front end, back end, database, and others. Add every server that you plan to use with your application to BMC Release Process Management, using the procedure described in Use case 1: Add a hardware or virtual server involved in the release process.
- Create software components that are necessary for release delivery and for application operation in the target environment, using the procedure described in Use case 3: Create components of the release.
- Create the environments to support your release life cycle. You might need a separate environment for development, quality assurance, user acceptance testing, and production.
In BMC Release Process Management, an environment contains all the infrastructure elements required to deploy an application on a particular stage of the release life cycle.
Your typical environment might contain several physical or virtual servers, hosted applications that are necessary for the successful deployment and operation of the released software (for example, web servers, application servers, database servers, and legacy applications), specific configuration settings for these servers and hosted applications, and finally, the network infrastructure that enables connectivity between the servers and hosted applications (for example, firewalls, SAN Storage, or network switches).
You can assign an opened or closed deployment policy to your environments. With an opened deployment policy, you can access the environment at any time, except during the time frame of the associated prevent deployment windows. With a closed deployment policy, you can access the environment only during the time frame of the associated allow deployment window. For more information about managing the access to your environments with deployment windows, see Managing deployment windows. - Create the application and select the servers on which you want to deploy the application.
- Create deployment windows for the application environments.
A deployment window is a calendar event that allows or prevents the deployment of an application to a particular environment based on the environment deployment policy. You can create single deployment window events or a series of deployment windows. - Create packages to manage binary files for applications, using the procedure described in Use case 7: Create packages, properties and references, and map packages to an application.
Use case 1: Add hardware servers or virtual servers for the release process
Create all the servers necessary for your release process on all phases.
For more information, see Managing servers.
Use case 2: Create environments for release deployment
Create environments that you are planning to use during your product release life cycle.
For more information, see Managing environments.
Use case 3: Create components of the release
Create all the components necessary for your release process on all phases.
For more information, see Managing components.
Create and then assign properties to the components.
For more information, see Create properties configuration.
Map components to external objects.
For more information, see Managing components.
Note
If an application depends on components in a separate application, the components in the other application are referred to as remote components. For example, the database component for an application named TravelTime might be supplied by a separate application named Oracle. In this case, the TravelTime application refers to the remote component in the Oracle application.
Use case 4: Create properties configuration
Create a property and assign components or servers to the property.
For more information, see Managing properties.
Allow modification of property value during the work task creation or request execution.
Use case 5: Create an application for the release
Create an application for the release.
For more information about applications, see Managing applications.
Add the environments that the application will go through during the release process.
For more information about environments, see Managing environments.
Add components.
For more information about components, see Managing components.
Associate components with the environments.
For more information, see Associating components with environments.
Note
An application might have a three-tier architecture, in which case a component could be an application server, a database, and a load balancer.
Use case 6: Create environment routes, promotion policies, and deployment windows
Create routes to determine the order in which environments are accessed by the application.
For more information, see Managing routes.
Create a plan template to structure the release plan of your software.
For more information, see Managing plans.
Add stages (Development, QA, Staging, Production and so on) to the plan template.
For more information, see Managing plans.
Create a plan to organize the software release process.
For more information, see Managing plans.
Add routes to a plan.
For more information, see Managing plans.
Create a plan run to assemble requests from different applications and different environments in an executable flow.
For more information, see Managing plan runs.
Create deployment windows or deployment windows series to manage access to the environments.
Use case 7: Create packages, properties and references, and map packages to an application
Create a package to manage binary files for applications.
For more information, see Managing packages.
Add existing properties to the package or create new properties for the package.
For more information, see Managing packages.
Add references to the package.
For more information, see Managing packages.
Assign packages to an application.
For more information, see Managing packages.
Comments
Log in or register to comment.