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 alter 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 it's not necessary 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 BuildMaster on Windows, Linux, or cloud servers to better mimic and interact with your current infrastructure. BuildMaster can be used with an agent or agentless
For this tutorial we'll be using a very simple web application called Accounts, and we'll manually upload 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, TeamCity, 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 App Pool into the block
Drag Deploy Artifact below stop AppPool
Add in Deploy Configuration File
Last, add Start App Pool (AccountsAppPool) 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 move onto the 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 use a simple pipeline that will deploy the release package throughout various environments and finally into production.
Pipelines are created by combining various stages, gates, and environments that a release package must go through in order to be successfully deployed to production. BuildMaster allows and encourages applications to have multiple pipelines for the different deployment scenarios that may arise.
BuildMaster also generates a simple pipeline automatically when an application is created with the application name, we'll use the generated pipeline for this demo. The pipeline has three stages: Integration, Testing, and Production.
Pipelines > Accounts
Most stages will have a target, but it's not required. You can see that each stage on our pipeline is already assigned the plan we've created, and is assigned an environment, but we need to set a server or server role. At the Integration stage click 'edit' on the 'Deploy Accounts' line. 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.
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 (like:TFS, TeamCity, or Jenkins), 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 turns 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.