BuildMaster gives the entire team visibility into the release status of an enterprises entire application suite by creating release pipelines in an organized, and easy to understand way. The first step in this process is creating the pieces that are needed for testing and deployment through the various stages of your Release.
In Part 1 of this tutorial, we’ll be creating several aspects of a release including: creating an Application, creating a Configuration File, and creating a Deployment Plan. We will then use these resources to create a Pipeline that will deploy the application through multiple stages and into production.
If you haven't already, download and install a local copy of BuildMaster. This tutorial will work entirely on your local machine so there is no reason to install BuildMaster on any servers or other infrastructure at this point.
Once you begin more rigorous testing of BuildMaster, you may want to install the BuildMaster agent on Windows, Linux, or cloud servers to better mimic and interact with your current infrastructure.
For this tutorial we'll be using a very simple web application called Accounts, and we'll manually uploading it to BuildMaster. If you've tried our Otter Tutorial, this will be the same Application.
You can download Accounts.zip here.
You can of course set BuildMaster to automatically pull from any Continuous Integration tool, like TFS or Jenkins. You can also create an artifact from within BuildMaster, or pull an artifact stored in a package repository like ProGet.
From the navigation select Applications and name the application "Accounts".
Applications > Create Application > Name = Accounts > Create
In BuildMaster, you can store and use Configuration Files that can be deployed as needed. BuildMaster stores configuration files by application and can be used in multiple environments with variables.
Assets > Configuration Files > Create New Configuration File > File Name = web.config
This will create a new configuration instance for the Integration, Testing, and Production environments. These are the pre-installed environments in BuildMaster; they can be edited, removed, or added to easily. Currently there are no configurations saved; to add a configuration click edit.
This will open a new tabbed-folder page with a tab for each environment along the left side.
Open the web.config file located in Accounts.zip, then copy / paste it in the Integration tab.
In the file you'll see 2 key value pairs (highlighted above), we'll need to modify this section since this isn't the Otter tutorial. Delete the second set and make sure the value for the remaining one is "Integration".
Use this same file and paste it in the Testing and Production tab changing the value to match the environment in each tab.
For a simple and repeated configuration file like this, it's common to create a template, but for this example we don't need to.
Deployment Plans provide an easy-to-understand, visual representation of the "code" that's directing and structuring a deployment. You'll find a simple plan started called Deploy Accounts. BuildMaster creates a simple plan for each application automatically. To start click on:
Plans > Deploy Accounts
The Plan has 3 blocks - we'll delete the Log Information, and the sleep blocks first. Then we can edit the General Block. Because over-commenting in plans should be avoided, General Blocks are an easy way to group different parts of a plan and also to set restrictions on them.
Next drag Stop AppPool into the block
Drag Deploy Artifact below stop AppPool
Add in Deploy Configuration File
Last, add Start AppPool and save the plan.
After dragging all the pieces into the general block, your deployment plan will be complete. You can also view the plan in text mode. BuildMaster maintains parity between visual mode and text mode to allow for flexibility and ease of editing.
Now that we have all the pieces in place, we can create a Release Pipeline. But first, since this is just a sample application you will need to create and start an IIS AppPool on your local machine with the name "AccountsAppPool".
Now that all of the resources for our Accounts application are set, we can create a simple pipeline that will deploy the release package throughout various environments and finally into production.
Pipelines > Create Pipeline > Name = Standard Accounts > Save
BuildMaster allows and encourages applications to have multiple pipelines for different deployment scenarios; we'll note that this is the pipeline for standard releases.
Pipelines are created by adding various stages, gates, and environments that a release package must go through in order to be successfully deployed to production. For this demo we're going to add 3 stages: Integration, Testing, and Production.
These are added by simply clicking the add stage button and typing the names in order.
Once the stages are added, we can add Gates, Notifiers, and Targets. Gates are approvals that are needed for an application to move into a stage. Notifiers can be set to alert specific personnel of when a specific action has occurred. Targets consist of a deployment plan, environments and servers. These elements describe how and where a release package is deployed per stage.
Most stages will have a target, but it's not required. Click 'add target' in the Integration stage. We'll use the name of the plan we've already created, and choose the current environment. We'll set the server option to 'Specific servers', and the server that BuildMaster is running on. A more common practice would be to group servers by application and environment, then selecting the appropriate group.
We'll do the same thing for targets in Testing and Production with the environment appropriately changed to match.
Let's add a manual approval gate for the Testing stage. Click add approval, and select User Approval. A specific user or a group of users can then be selected. When a specific user is selected that user must approve the release package before it can move forward. When a group of users any one of that group can approve the release package. In this example any administrator can give their approval when smoke tests have passed.
There are other gates available, including both manual and automated approvals. Examples includes: group approvals where a set number of users must give approval, automatic approvals like checking for specific files, or if specific Unit Tests have passed.
We've now created application resources and an application pipeline, now we need to deploy a release package through our pipeline.
Start by creating a new release for the Accounts application.
Releases > Create Release > Create Release
Click create package, and un-select 'Automatically deploy to Integration stage' and then click create package.
We now need to upload the Accounts Artifact (that we downloaded earlier). On the Release overview page there is an option for manual upload. Select manual upload, with Websites as the artifact name and choose the Accounts.zip file you downloaded earlier. Normally, this would happen automatically by integrating a CI tool with BuildMaster, but a manual upload allows for completed applications to also be added into pipelines.
After you've uploaded the artifact click on 'deploy' in the integration box. The stage should turn green indicating success.
The testing stage is orange (above) because it cannot yet be promoted. We installed a gate at this step and we must first approve the release package for this stage. This is done by clicking the check-box under approvals. Once it is approved the box to Testing turns blue indicating that you can now deploy to this stage.
You can now deploy the build through the rest of your pipeline and through to Production.
If you set Accounts up in IIS you can visit it in your browser.