End-to-end process

This topic summarizes the basic steps for using the BMC Varalogix Q Deployment Automation product. Click the links for detailed steps or further information. For an example of a basic deployment, see Example-of-a-web-application-deployment.

  1. Review the prerequisites and ensure that:
    1. The system is installed and configured so that a user can log on
    2. For each application that you plan to deploy, source files and other content needed by the application are in place
    3. For each deployment target, the destination is ready and available
  2. Log on to the system as an administrative user so that you have access to all tabs and functions. 
  3. Add a server definition for each computer in your network.
    For each server, define the host name and select the agent for communication.
  4. Create a new package and define every application component using an URI reference that defines the interface method, server, and location of the file.
    Ensure that you enter the URI in the appropriate format for your platform (file:///tmp/sample.htm for UNIX, or file:///C:\Temp\sample.htm for Windows).
    Example:     Suppose your application consists of a WAR file and a SQL file. You need a package with two references.
  5. Create an instance from the new package.
    Review the log to ensure that the system has imported all data into the package. Ensure that you have all the necessary components for a deployable entity.
  6. Configure the deployment topology, which defines the targets for the deployment and any dependencies, and which represents your business infrastructure:
    1. Create channel templates.
      A channel is a logical target that represents a service, such as WebSphere or Apache. The root directory defines the directory level for channel access, and should be a physical path on the server, such as /var/www or C:\apache\htdocs (use the format appropriate for your platform, UNIX or Windows). 
      Templates enable you to organize according to service categories, such as templates for all WebSphere systems. Eventually, you will want to create a template for every action pack (group of actions). 

    2. Create channels based on the previously defined channel templates.
      Channels correspond to servers in the system. You can add a load balancer to the channel. 

      Channels are only outbound. Incoming data always goes to the deployment server and always deploys to logical endpoints. Channels associate those logical endpoints to the physical targets.

  7. Create environments and add the previously created channels to them. 

    Environments define a relationship between logical endpoints (channels), such as between a database and web server. Packages are targeted to an environment. You can think of the environment as the collection of services that your application needs to run. You can define an environment around a business stage or function, such as QA, Staging, Production, and so on, or around clusters of similar servers, such as database or web servers.

  8. Create routes and add environments into the routes. 

    A route is a business model concept: a route connects environments in a sequence, with at least one environment per route. Routes enable you to model your business flow, such as the application development flow from QA to staging to production. If multiple environments are in a route, you can specify the order of progression through each, and you can create decision points at each step to control promotion to the next step. An application might have multiple routes through a test and a production environment.  

    • If the route is open, you can select any environment in the route.
    • If the route is strict, the instance must be deployed to the first environment identified in the route.
  9. Construct the deployment process for each type of content defined in the package.
    For example, if your package contains a WAR file and a SQL file, you need a process for each. 
    1. To define the deployment tasks for the process, add one or more activities.
      Activities are basic building blocks with parameters that enable them to be reused in different environments. They represent single execution steps or commands within the deployment, such as copying a file or stopping and restarting a service.
    2. Add triggers to each process to identify the content to be deployed.
      A process has one or more triggers, which determine if or when the process deploys. For example, you could create triggers for a deployment process to ensure that the content is in place before deploying. 
  10. Deploy the package to the route.
    In the deployment launchpad, you can drag and drop the package onto the route to create an instance and then deploy it automatically.
    1. Examine the logs to find any deployment problems.
    2. When you are satisfied with that step, you can promote the deployment to the next environment in the route, for example, from testing to staging.
    3. When you are satisfied that everything works as planned, you can create a schedule to run the deployment step on a regular basis. 

The deployment is complete. 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*