BuildMaster is an application release automation tool. In this tutorial, we will demonstrate how to create a release package from Source Control and deploy it all the way through production.
Build Artifacts can be added to a Release Package in four different ways: pulled from a package manager, imported from a CI server, created in BuildMaster, or manually uploaded.
In this tutorial, we’ll be building a Build Artifact within BuildMaster using an outside repository. In this case, we’ll be using GitHub as our repository for an application called Accounts.
If you’d like to follow along step-by-step, you can fork the Accounts Repository into your own account.
Click Administration > Click BuildMaster Extensions > Click GitHub > Click Install This Extension
Click Administration > Click BuildMaster Extensions > Click NuGet > Click Install This Extension
After the extensions are installed, BuildMaster will automatically restart, and both GitHub and NuGet will now be in the Up-to-Date Extensions.
Click Administration > Click Resource Credentials > Click Create Credential > Click GitHub
We’ll create a GitHub resource credential by filling out appropriate fields like User name, Repository, and Password . NuGet requires no additional configuration.
Click Applications > Click Create Application > Set Name to Accounts > Click Create
When creating the application, the Integration, Testing, and Production environments will be added by default as the initial pipeline.
Click Plans > Click Deploy Accounts
BuildMaster has automatically created a simple deployment plan by default. The plan doesn't do much, but we can edit it so that it will deploy the artifact that we'll import through the pipeline.
Edit the General Block, and set a server for the plan to be run on. Note that you can also target environments and servers to execute operations on from the pipeline stage, but for this tutorial, we’ll just set it here.
Next, drag a Deploy Artifact operation into the edited General Block. Set the Artifact name to “Websites”, and the Target directory to C:\Websites\$EnvironmentName\Accounts. Using $EnvironmentName will create a new folder for each environment that the application is deployed to, and demonstrates one way to generalize a deployment plan for use in multiple environments.
After saving the Deploy Artifact Operation save the plan.
This plan will only deploy an Artifact. First we must create the artifact (Websites) which we will do in BuildMaster. So, we need to create a new plan called Build Accounts.
Crate a plan by clicking the Create Plan button and name the plan Build Accounts
First, add a General Block with a short description, like “Build Accounts Website.”
Next, we’ll add a Get Source operation that will pull the latest files from a repository (in this case, GitHub) and store them in a temporary workspace called $WorkingDirectory. We’ll use the GitHub resource credential we’ve already created.
Now, we’ll add a Write Assembly Versions operation which will increase the build number by 1 each time by default.
Since this build requires NuGet packages, the next step is to drag an Install NuGet Packages operation with default settings.
Now we are prepared to build our Accounts web application simply by adding a Build MSBuild Project operation with the appropriate solutions and configurations.
To turn this build into an Artifact, add a Create Artifact operation. Name the artifact “Websites” because that is the artifact that we used in the deployment plan we first created.
You can view the plan in either visual mode or text mode.
When we created the application, a simple pipeline was also created which we can now edit.
Click Pipelines > Click Accounts
You can see that the three stages-Integration, Testing, and Production-are all in the pipeline and all have the Deploy Account plan assigned to them already. All we need to do is create the Artifact with our build plan; we’ll create a new Stage for that.
Click Add Stage > Set Name to Build > Set Pipeline position to 0 > Click Save Stage
We’ll add a target to the Build stage using our build plan (Build Accounts) and our local server.
After setting the build target, we will create a Release that builds and deploys this artifact. The release number can be anything, but defaults to 0.0.0.
Click Releases > Click Create Release > Click Create Package
BuildMaster will now run the build plan we've set up and create the artifact.
We can see that there has been an artifact created called “Website.”
You can now run the artifact through the rest of the pipeline simply by clicking [Deploy] in each successive stage. Of course, you can also configure gates, listeners, permissions to ensure that a proper process is followed.
You can further verify that the deployment was successful by checking the drive used when setting up the deployment plan. There will be three folders under /Website -one for Integration, Testing, and Production, all with the deployed files.