The things that Automation builds: a virtual case of a financial web site

Introduced

The first part of this series discusses some of the benefits of automating your build and deployment processes. There are a number of reasons why you should do this: make your developers focus more on the core business than on process management, reduce human-induced errors, reduce the time spent on deployment, and many other reasons. Regardless of your motivation, automating your build process is always the right answer.

In this article, we will take the corporate web site of a virtual financial institution as an example to automate the construction process step by step.

Case description

Our company is called the Third National Bank (3rd), a local business organization. Our online banking applications include a front-end Web application layer (asp.net), a restful service layer for mobile applications (WEBAPI), a series of internal service layers (WCF) that use traditional domain-driven design to separate business logic, domain objects, and data access, and a SQL Server database.

The software team uses mercurial as the source control system and periodically delivers new features using the policy of attribute branching. This policy creates a new branch for each new feature or bug, and the branch code merges the master branch waiting for publication after the test completes.

At this stage, all the build and deploy processes are done manually by the software team, causing developers to spend several hours a week, stopping their coding efforts to maintain their repositories and servers. We are trying to change the status quo and automate as many processes as possible.

Build Scripts

Building scripts is the first step in automating the build process. The format of the script can be varied: it can be a shell or batch file, an xml-based file, or written by an existing or custom programming language, can be handwritten or auto-generated, or it can be completely hidden from the IDE's environment. Your process can even use a combination of multiple technologies. In this example, we use Nant as the build script engine.

In our environment, front-end Web applications, exposed services, and internal services are separate Visual Studio solutions, and SQL databases are separate database solutions. We'll create a master build script file 3rdnational.master.build, which looks almost like this:

<project name= "3rd National Bank" default= "builds" >
   <target name= "Build" >
     <call target= " Createstagingenvironment "/>
     <nant buildfile=" Bankdb/bankdb.build "target=" Build "/>
     Buildfile= "Servicelayer/servicelayer.build" target= "Build"/>
     <nant buildfile= "onlinebanking/" Webui.build "target=" Build "/>
     <nant buildfile=" Externalservices/externalservices.build "/>
   </ Target>
</project>

The script didn't do anything specific, it was just a build script that called the four solutions. Each solution has a build file that contains all the code for compiling and preparing this part of the application.

Now let's take a look at a build script for one of these solutions. Each solution is based on the same basic steps: preparation, compilation, and staging. Servicelayer.build is a basic compilation script, and its syntax is very easy to understand:

<project name= "Servicelayer" > <property name= "msbuildexe" value= "C:\windows\ Microsoft.net\framework\ V4.0.30319\msbuild.exe "/> <target name=" Build "> <call target=" Prepare "/> <call target=" Co Mpile "/> <call target=" stage "/> </target> <target name=" Prepare "> <!--Implement
       ation omitted--> </target> <target name= "Compile" > <exec program= "${msbuildexe}" > <arg value= "ServiceLayer.sln"/> <arg value= "/p:configuration=release"/> <arg value= "/t:rebu" Ild "/> </exec> </target> <target name=" Stage "> <copy todir=". /DEPLOY/BANKWCF "> <include name=" wcfservices/**/*.svc "/> <include name=" Wcfservices/**/*.asax " /> <include name= "wcfservices/**/*.config"/> <include "name=" Wcfservices/**/*.dll/>
 T;/copy> </target> </project>

The preparation steps can include generating AssemblyInfo files, recompiling agents, or any number of other tasks. The compilation step in this example simply calls MSBuild, which is the build engine that Visual Studio uses to compile the solution. When each step of the build succeeds, the final step is to copy the generated files to a staging area for later use.

We've done the same thing with the other three solutions, just making some tweaks based on different types of projects.

Writing build scripts, like writing code, can achieve the same effect in different ways. You can use the command-line compiler instead of MSBuild, you can build each project file separately instead of the entire solution, and you can use Msdeploy to temporarily save or deploy your application, instead of filtering and copying files. In the final analysis, it depends on which way you adapt. As long as your scripts generate consistent results, you can write them.