Continuous Integration

i
 Continuous Integration

About the Tutorial

Continuous Integration is a development practice that calls upon development teams to
ensure that a build and subsequent testing is conducted for every code change made to a
software program.

This concept was meant to remove the problem of finding the late occurrences of issues
in the build lifecycle. Instead of the developers working in isolation and not integrating
enough, continuous integration was introduced to ensure that the code changes and builds
were never done in isolation.

Audience
Continuous integration has become a very integral part of any software development
process. It will help the software testing professionals who would like to learn how to build
and test their projects continuously in order to help the developers integrate the changes
to the project as quickly as possible and obtain fresh builds.

Prerequisites
This is a preliminary tutorial that covers some of the most fundamental concepts of
Continuous Integration. Any professional having a good understanding of Software
Development should benefit from this tutorial.

Copyright & Disclaimer

 Copyright 2016 by Tutorials Point (I) Pvt. Ltd.

All the content and graphics published in this e-book are the property of Tutorials Point (I)
Pvt. Ltd. The user of this e-book is prohibited to reuse, retain, copy, distribute or republish
any contents or a part of contents of this e-book in any manner without written consent
of the publisher.

We strive to update the contents of our website and tutorials as timely and as precisely as
possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt.
Ltd. provides no guarantee regarding the accuracy, timeliness or completeness of our
website or its contents including this tutorial. If you discover any errors on our website or
in this tutorial, please notify us at [email protected]

i
 Continuous Integration

Table of Contents
About the Tutorial .................................................................................................................................... i

Audience .................................................................................................................................................. i

Prerequisites ............................................................................................................................................ i

Copyright & Disclaimer............................................................................................................................. i

Table of Contents .................................................................................................................................... ii

1. CI – OVERVIEW .................................................................................................................... 1

Why Continuous Integration? ................................................................................................................. 1

Workflow ................................................................................................................................................ 1

2. CI – SOFTWARE ................................................................................................................... 4

Installing Git ............................................................................................................................................ 5

Configuring Git ...................................................................................................................................... 13

Continuous Integration Server .............................................................................................................. 14

Installing TeamCity ................................................................................................................................ 15

Configuring TeamCity ............................................................................................................................ 23

The Build Tool ....................................................................................................................................... 28

Database Server .................................................................................................................................... 29

Web Server ........................................................................................................................................... 39

3. CI – REDUCING RISKS ......................................................................................................... 51

Risk 1 – Lack of Deployable Software .................................................................................................... 51

Risk 2 – Discovering Defects Late in the Lifecycle .................................................................................. 52

Risk 3 – Lack of Project Visibility............................................................................................................ 52

Risk 4 – Low Quality Software ............................................................................................................... 53

4. CI – VERSION CONTROL ..................................................................................................... 54

Purpose of the Version Control System ................................................................................................. 54

Working with Git for Source Code Versioning Control System ............................................................... 55
ii
 Continuous Integration

Moving Source Code to Git .................................................................................................................... 56

5. CI – FEATURES ................................................................................................................... 58

6. CI – REQUIREMENTS .......................................................................................................... 59

7. CI – BUILDING A SOLUTION ............................................................................................... 61

Building a Solution in .Net ..................................................................................................................... 61

8. CI – BUILD SCRIPTS ............................................................................................................ 63

9. CI – BUILDING ON THE SERVER .......................................................................................... 65

10. CI – CHECKING IN SOURCE CODE ....................................................................................... 70

11. CI – CREATING A PROJECT IN TEAMCITY ............................................................................ 72

12. CI – DEFINING TASKS ......................................................................................................... 87

13. CI – BUILD FAILURE NOTIFICATIONS .................................................................................. 95

14. CI – DOCUMENTATION AND FEEDBACK........................................................................... 106

Metrics ................................................................................................................................................ 106

Detailed View of Build Metrics ............................................................................................................ 110

15. CI – CONTINUOUS TESTING ............................................................................................. 111

16. CI – CONTINUOUS INSPECTION ....................................................................................... 126

Download and Install NCover .............................................................................................................. 126

Configure the Project in TeamCity to Use NCover ............................................................................... 131

17. CI – CONTINUOUS DATABASE INTEGRATION ................................................................... 139

18. CI – CONTINUOUS DEPLOYMENT .................................................................................... 157

19. CI – BEST PRACTICES........................................................................................................ 182

iii
 1. CI – Overview Continuous Integration

Continuous Integration was first introduced in the year 2000 with the software known as
Cruise Control. Over the years, Continuous Integration has become a key practice in any
software organization. This is a development practice that calls upon development teams
to ensure that a build and subsequent testing is conducted for every code change made
to a software program. This concept was meant to remove the problem of finding late
occurrences of issues in the build lifecycle. Instead of the developers working in isolation
and not integrating enough, Continuous Integration was introduced to ensure that the
code changes and builds were never done in isolation.

Why Continuous Integration?

Continuous integration has become a very integral part of any software development
process. The continuous Integration process helps to answer the following questions for
the software development team.

 Do all the software components work together as they should? – Sometimes

systems can become so complex that there are multiple interfaces for each
component. In such cases, it’s always critical to ensure that all the software
components work seamlessly with each other.

 Is the code too complex for integration purposes? – If the continuous integration
process keeps on failing, there could be a possibility that the code is just too
complex. And this could be a signal to apply proper design patterns to make the
code lesser complex and more maintainable.

 Does the code adhere to the established coding standards? – Most of the test cases
will always check that the code is adhering to the proper coding standards. By doing
an automated test after the automated build, this is a good point to check if the
code meets all the desired coding standards.

 How much code is covered by automated tests? – There is no point in testing code
if the test cases don’t cover the required functionality of the code. So it’s always a
good practice to ensure that the test cases written should cover all the key
scenarios of the application.

 Were all the tests successful after the latest change? – If a test fails, then there is
no point in proceeding with the deployment of the code, so this is a good point to
check if the code is ready to move to the deployment stage or not.

Workflow
The following image shows a quick workflow of how the entire Continuous Integration
workflow works in any software development project. We will look at this in detail in the
subsequent chapters.

1
 Continuous Integration

All source code is kept in a

source code repository
system

Developer checks in the

new code into the source
code repository system

The Continuous
Integration server will
pick up the software
and it changes and
starts building the
checked in project.

If the build is a failure,

the team will be notified
accordingly. If the build
has passed, then it is
tested for any defects.

If the tests fail, then the

developers are notified.
If the tests pass, then
the build is ready to be
deployed to the
relevant server
environment.

So, based on the above workflow, this is generally how the continuous integration process
works.

 First, a developer commits the code to the version control repository.

Meanwhile, the Continuous Integration server on the integration build machine
polls source code repository for changes (e.g., every few minutes).

 Soon after a commit occurs, the Continuous Integration server detects that
changes have occurred in the version control repository, so the Continuous

2
 Continuous Integration

Integration server retrieves the latest copy of the code from the repository and
then executes a build script, which integrates the software.

 The Continuous Integration server generates feedback by e-mailing build

results to the specified project members.

 Unit tests are then carried out if the build of that project passes. If the tests are
successful, the code is ready to be deployed to either the staging or production
server.

 The Continuous Integration server continues to poll for changes in the version
control repository and the whole process repeats.

3
 2. CI – Software Continuous Integration

The software part is the most important aspect of any Continuous Integration process.
This chapter focusses on the software which will be needed for the entire Continuous
Integration process.

Source Code Repository

The source code repository is used for maintaining all the source code and all the changes
made to it. The two most popular ones for source code repository management is
subversion and Git with Git being the most recent popular system. We will now look at
how to get Git installed on the system.

System Requirements
Memory 2 GB RAM (recommended)

200 MB HDD for the installation. Additional storage is required to

Disk Space store the project source code and this is dependent on the source
code being added.

Operating System Can be installed on Windows, Ubuntu/Debian, Red

Version Hat/Fedora/CentOS, Mac OS X.

4
 Continuous Integration

Installing Git
Step 1: The official website for Git is https://git-scm.com/. If you click on the link, you
will get to the home page of the Git official website as shown in the following screenshot.

5
 Continuous Integration

Step 2: To download Git, just scroll down the screen and go to the Downloads section and
click Downloads.

6
 Continuous Integration

Step 3: Click the Windows link and the download for Git will begin automatically.

7
 Continuous Integration

Step 4: Click the downloaded .exe file for Git. In our case, we are using the Git-2.6.1-64-
bit.exe file. Click Run which comes appears on the next screen.

8
 Continuous Integration

Step 5: Click the Next button that appears on the following screen.

Step 6: Click Next in the following screen to accept the General License agreement.

9
 Continuous Integration

Step 7: Choose the location for your Git installation.

Step 8: Click Next to accept the default components that are need to be installed.

10
 Continuous Integration

Step 9: Choose the option of ‘Use Git from the Windows command prompt’ since we are
going to be using Git from Windows.

Step 10: In the following screen, accept the default setting of ‘Checkout Windows-style,
commit Unix-style line endings’ and click Next.

11
 Continuous Integration

Step 11: In the following screen, choose the option of ‘Use Windows default console
window’, since we are using Windows as the system for installation of Git.

The installation will now start, and the subsequent steps can be followed for configuring
Git, once the installation is complete.

12
 Continuous Integration

Configuring Git
Once Git has been installed, the configuration steps need to be carried out for the initial
configuration of Git.

The first thing that needs to be done is to configure the identity in Git and then to configure
a user name and email. This is important because every Git commit uses this information,
and it’s immutably baked into the commits you start creating. One can do this by opening
the command prompt and then enter the following commands –

git config –global user.name “Username”

git config –global user.email “emailid”

The following screenshot is an example for better understanding.

These commands will actually change the configuration file of Git accordingly. To ensure
your settings have taken effect, you can list down the settings of the Git configuration file
by using issuing the following command.

git config --list

13
 Continuous Integration

An example of the output is shown in the following screenshot.

Continuous Integration Server

The next crucial software required for the entire continuous integration pipeline is the
Continuous Integration software itself. Following are the most commonly used Continuous
Integration softwares used in the industry –

 Jenkins – This is an open source Continuous Integration software which is used

by a lot of development communities.

 Jet Brains TeamCity – This is one of the most popular commercial Continuous
Integration software’s available and most companies use this for their Continuous
Integration needs.

 Atlassian Bamboo – This is another popular Continuous Integration software

provided by a company called Atlassian Pvt. Ltd.

All of the softwares mentioned above, work on the same model for Continuous Integration.
For the purpose of this tutorial, we will look at Jetbrains TeamCity for the Continuous
Integration server.

14
 Continuous Integration

Installing TeamCity
Following are the steps and the system requirements for installing Jet Brains TeamCity in
your computer.

System Requirements
Memory 4 GB RAM (recommended)

1 GB HDD for the installation. Additional storage is required to store

Disk Space
the build workspace for each project.

Operating
Can be installed on Windows, Linux, Mac OS X.
System Version

Installation
Step 1: The official website for TeamCity is https://www.jetbrains.com/teamcity/. If you
click the given link, you will go to the home page of the TeamCity official website as shown
in the following screenshot. You can browse the page to download the required software
for TeamCity.

15
 Continuous Integration

Step 2: The downloaded .exe is being used for the purpose of executing TeamCity-
9.1.6.exe. Double-click the executable and then click Run in the next screen that pops
up.

16
 Continuous Integration

Step 3: Click Next to start the setup.

17
 Continuous Integration

Step 4: Click the ‘I Agree’ button to accept the license agreement and proceed with the
installation.

18
 Continuous Integration

Step 5: Choose the location for the installation and click Next.

19
 Continuous Integration

Step 6: Choose the default components for the installation and click Next.

This will start the installation process. Once completed the configuration process will
follow.

20
 Continuous Integration

Step 7: Choose a port number for the server to run. Best is to use a different port such
as 8080.

21
 Continuous Integration

Step 8: Next it will ask for which account TeamCity needs to run as. Choose the SYSTEM
account and Click Next.

22
 Continuous Integration

Step 9: Next it will ask for the services which needs to be started. Accept the default ones
and then click Next.

Configuring TeamCity
Once the installation is complete, the next step is the configuration of TeamCity. This
software can be opened by browsing on the following URL in the browser –

http://locahost:8080

23
 Continuous Integration

Step 1: The first step is to provide the location of the builds, which will be carried out by
TeamCity. Choose the desired location and click the Proceed button.

24
 Continuous Integration

Step 2: The next step is to specify the database for storing all the TeamCity artefacts. For
the purpose of the tutorial, one can choose the Internal (HSQLDB), which is an internal
database that is best suited when using products for testing purposes.

TeamCity will then process all the necessary steps to get it up and running.

25
 Continuous Integration

Step 3: Next you will be requested to Accept the license agreement. Accept the same and
click Continue.

26
 Continuous Integration

Step 4: You need to create an administrator account that will be used to log into the
TeamCity software. Enter the required details and click the ‘Create Account’ button.

27
 Continuous Integration

You will now be logged into TeamCity.

The Build Tool

The Build tool is a tool which ensures that the program is built in a particular way. The
tool will normally carry out a list of tasks, which are required for the program to be built
in a proper manner. Since in our example, we are going to be looking at a .Net program,
we will be looking at MSBuild as the build tool. The MSBuild tool looks at a build file which
contains a list of tasks that are used to build the project. Let’s look at a typical Build file
for a web configuration project.

Following are the key sections of the Build file, which need to be considered.

IIS Settings
Following settings are used to determine which is the port number, what is the path on
the web server and what type of authentication is required when the application is run.
These are important settings, which will be changed via the MSBuild command when we
learn how the deployment will be carried out later on in the tutorial.

28
 Continuous Integration

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup
This is used to tell the Build server what are all the dependent binaries that are required
to run this project.

<ItemGroup>
<Reference Include="System.Web.ApplicationServices" />
<Reference Include="System.ComponentModel.DataAnnotations" />

<ItemGroup>
<Compile Include="App_Start\BundleConfig.cs" />
<Compile Include="App_Start\FilterConfig.cs" />

.Net Framework Version

The TargetFrameworkVersion tells which is the version of .Net that needs to be present
for the project to work. This is absolutely required because if the build server does not
have this in place, the build will fail.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Deployment Environment – Amazon

For the purpose of this tutorial, we will ensure our Continuous Integration server has the
ability to deploy our application to Amazon. For this, we need to ensure the following
artefacts are in place.

Database Server
Perform the following steps to ensure that the database server is in place in Amazon for
the deployment.

Step 1: Go to the Amazon Console - https://aws.amazon.com/console/

Login with your credentials. Note that you can apply for a free id on the amazon site, which
will allow you to have a free tier that allows you to use some of the resources on Amazon
free of cost.

29
Continuous Integration

30
 Continuous Integration

Step 2: Go to the RDS Section to create your database.

31
 Continuous Integration

Step 3: Click Instances in the next screen that pops up.

32
 Continuous Integration

Step 4: Click the Launch DB option in the next screen that comes up.

33
 Continuous Integration

Step 5: Choose the SQL Server tab and then choose the Select option for SQL Server
Express.

34
 Continuous Integration

Step 6: Ensure that the following details are entered to confirm that you are using the
free tier of databases available from Amazon.

35
 Continuous Integration

Step 7: Click the Next Step button once all the fields are filled.

36
 Continuous Integration

Step 8: In the next screen that comes up, accept all the default settings and Click Launch
DB Instance.

37
 Continuous Integration

Step 9: You will then be presented with a screen that says that the DB is being successfully
launched. On the same page, there will be a button to view the DB Instance. Click the link
to see your DB Instance being set up.

38
 Continuous Integration

After some time, the status of the above screen will change to notify that the DB Instance
has been successfully created.

Web Server
The next step is to create your web server on Amazon, which will host the web application.
This can be done by following the subsequent steps to have this in place.

39
 Continuous Integration

Step 1: Go to Amazon Console - https://aws.amazon.com/console/

Login with your credentials. Note that you can apply for a free id on the Amazon site,
which will allow you to have a free tier that allows you to use some of the resources on
Amazon free of cost.

40
 Continuous Integration

Step 2: Go to the EC2 section to create your web server.

41
 Continuous Integration

Step 3: In the next screen, click Launch Instance.

42
 Continuous Integration

Step 4: Click Windows – Microsoft Windows Server 2010 R2 Base.

43
 Continuous Integration

Step 5: Choose the t2.micro option, which is a part of the free tier. Click Next: Configure
Instance Details.

44
 Continuous Integration

Step 6: Accept the default settings on the next screen that comes up and then choose the
option Next: Add Storage.

45
 Continuous Integration

Step 7: Accept the default settings on the next screen and choose the option Next: Tag
Instance.

46
 Continuous Integration

Step 8: Accept the default settings on the next screen and choose the option of Next:
Configure Security Group.

47
 Continuous Integration

Step 9: Accept the default settings on the next screen and choose the option of Review
and Launch.

48
 Continuous Integration

Step 10: Click Launch in the next screen that comes up.

49
 Continuous Integration

Step 11: In the next screen that comes up, you will be prompted to create a key pair.
This will be used to log into the server at a later point of time. Just create the key pair and
click Launch Instance.

The instance will now be set up in Amazon.

50
 3. CI – Reducing Risks Continuous Integration

There are chances that things will go wrong on a project. By effectively practicing CI, you
find out what happens at every step along the way, rather than later when the project is
into the development cycle. CI helps you identify and mitigate risks when they occur,
making it easier to evaluate and report on the health of the project based on concrete
evidence.

This section is going to concentrate on the risks that can be avoided by using Continuous
Integration.

On any project, there are many risks that need to be managed. By eliminating the risks
earlier in the development lifecycle, there are lesser chances of these risks developing into
issues later on, when the system actually goes live.

Risk 1 – Lack of Deployable Software

“It works on my machine but does not work on another” – This is probably one of
the most common phrases encountered in any software organization. Because of the
number of changes done to software builds on a daily basis, sometimes there is little
confidence on whether the build of the software actually works or not. This concern has
the following three side effects.

 Little or no confidence in whether we could even build the software.

 Lengthy integration phases before delivering the software internally (i.e., test
team) or externally (i.e., customer), during which time nothing else gets done.

 Inability to produce and reproduce testable builds.

Solution
Eliminating tight coupling between the IDE and the build processes. Use a separate
machine solely for integrating the software. Ensure that everything you need to build the
software is contained in the version control repository. Finally, create a Continuous
Integration system.

The Continuous Integration server can watch for changes in the version control repository
and run the project build script when it detects a change to the repository. The capability
of the Continuous Integration system can be increased to include having the build run
through tests, perform inspections, and deploy the software in the development and test
environments; this way you always have a working software.

“Inability to synchronize with the database” – Sometimes developers are unable to

recreate the database quickly during development, and hence find it difficult to make
changes. Often this is due to a separation between the database team and the
development team. Each team will be focused on their own responsibilities and have little
collaboration between each other. This concern has the following three side effects –

 Fear of making changes or refactoring the database or source code.

 Difficulty in populating the database with different sets of test data.

51
 Continuous Integration

 Difficulty in maintaining development and testing environments (e.g.,

Development, Integration, QA, and Test).

Solution
The solution to the above issue is to ensure that the placement of all database artifacts in
the version control repository are carried out. This means everything that is required to
recreate the database schema and data: database creation scripts, data manipulation
scripts, stored procedures, triggers, and any other database assets are needed.

Rebuild the database and data from your build script, by dropping and recreating your
database and tables. Next, apply the stored procedures and triggers, and finally, insert
the test data.

Test (and inspect) your database. Typically, you will use the component tests to test the
database and data. In some cases, you’ll need to write database-specific tests.

Risk 2 – Discovering Defects Late in the Lifecycle

Since there are so many changes which happen frequently by multiple developers to the
source code, there are always chances that a defect can be introduced in the code that
could only be detected at a later stage. In such cases, this can cause a big impact because
the later the defect is detected in the software, the more expensive it becomes to remove
the defect.

Solution
Regression Testing – This is the most important aspect of any software development
cycle, test and test again. If there is any major change to the software code, it is absolutely
mandatory to ensure that all the tests are run. And this can be automated with the help
of the Continuous Integration server.

Test Coverage – There is no point in testing if the test cases do not cover the entire
functionality of the code. It is important to ensure that the test cases created to test the
application are complete and that all code paths are tested.

For example, if you have a login screen which needs to be tested, you just can’t have a
test case that has the scenario of a successful login. You need to have a negative test case
wherein a user enters a different combination of user names and passwords and then it is
required to see what happens in such scenarios.

Risk 3 – Lack of Project Visibility

Manual communication mechanisms require a lot of coordination to ensure the
dissemination of project information to the right people in a timely manner. Leaning over
to the developer next to you and letting them know that the latest build is on the shared
drive is rather effective, yet it doesn’t scale very well.

What if there are other developers who need this information and they are on a break or
otherwise unavailable? If a server goes down, how are you notified? Some believe they
can mitigate this risk by manually sending an e-mail. However, this cannot ensure the
information is communicated to the right people at the right time because you may
accidentally leave out interested parties, and some may not have access to their e-mail at
the time.

52
 Continuous Integration

Solution
The Solution to this issue is again the Continuous Integration server. All CI servers have
the facility to have automated emails to be triggered whenever the builds fail. By this
automatic notification to all key stakeholders, it is also ensured that everyone is on board
on what is the current state of the software.

Risk 4 – Low Quality Software

There are defects and then there are potential defects. You can have potential defects
when your software is not well designed or if it is not following the project standards, or
is complex to maintain. Sometimes people refer to this as code or design smells — “a
symptom that something may be wrong.”

Some believe that lower-quality software is solely a deferred project cost (after delivery).
It can be a deferred project cost, but it also leads to many other problems before you
deliver the software to the users. Overly complex code, code that does not follow the
architecture, and duplicated code - all usually lead to defects in the software. Finding these
code and design smells before they manifest into defects can save both time and money,
and can lead to higher-quality software.

Solution
There are software components to carry out a code quality check which can be integrated
with the CI software. This can be run after the code is built to ensure that the code actually
conforms to proper coding guidelines.

53
 4. CI – Version Control Continuous Integration

Version control systems, also known as source control, source code management systems,
or revision control systems, are a mechanism for keeping multiple versions of your files,
so that when you modify a file you can still access the previous revisions.

The first popular version control system was a proprietary UNIX tool called SCCS (Source
Code Control System) which dates back to the 1970s. This was superseded by RCS, the
Revision Control System, and later CVS, Concurrent Versions System.

Now the most popular version control system used are Subversion and Git. Let’s first
look at why we need to use a versioning control system and next let’s look at putting our
source code in Git source code repository system.

Purpose of the Version Control System

One reason that we use the term version control in preference to source control is that
version control isn’t just for source code. Every single artifact related to the creation of
your software should be under version control.

 Developers should use it for source code – By default all source code needs to
be stored in the versioning control system.

 Related artefacts – Every system would be having related artefacts to the source
code such as database scripts, build and deployment scripts, documentation,
libraries and configuration files for your application, your compiler and collection of
tools, and so on. All of these compliment the entire development and deployment
process and also needs to be stored in the versioning control system.

By storing all the information for the application in source control, it becomes easier to re-
create the testing and production environments that your application runs on. This should
include configuration information for your application’s software stack and the operating
systems that comprise the environment, DNS Zone Files, Firewall Configuration, and so
forth.

At the bare minimum, you need everything required to re-create your application’s binaries
and the environments in which they run. The objective is to have everything that can
possibly change at any point in the life of the project stored in a controlled manner. This
allows you to recover an exact snapshot of the state of the entire system, from
development environment to production environment, at any point in the project’s history.

It is even helpful to keep the configuration files for the development team’s development
environments in version control since it makes it easy for everyone on the team to use the
same settings. Analysts should store requirements documents. Testers should keep their
test scripts and procedures in version control. Project managers should save their release
plans, progress charts, and risk logs here.

In short, every member of the team should store any document or file related to the
project in version control.

54
 Continuous Integration

Working with Git for Source Code Versioning Control System

This section will now focus on how Git can be used as a versioning control system. It will
focus on how you can upload your code to the versioning control system and manage
changes in it.

Our Demo Application

For the purpose of this entire tutorial we are going to look at a simple Web ASP.Net
application which will be used for the entire Continuous Integration Process. We don’t need
to focus on the entire code details for this exercise, just having an overview of what the
project does is sufficient for understanding the entire continuous integration process. This
.Net application was built using the Visual Studio Integrated Development
Environment.

The following screenshot is the structure of the solution in the Visual Studio environment.
It is a very simple Web application which has the main code in the Demo.aspx file.

The code in the Demo.aspx file is shown in the following program:

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>TutorialsPoint</title>
</head>
<body>
<form id="form1" runat="server">
<div>

55
 Continuous Integration

<%Response.Write("Continuous Integration"); %>

</div>
</form>
</body>
</html>

The code is very simple and just outputs the string “Continuous Integration” to the
browser.

When you run the project in Google Chrome, the output will be as shown in the following
screenshot.

Moving Source Code to Git

We are going to show how to move the source code to Git from the command line interface,
so that the knowledge of how Git can be used is clearer to the end user.

Step 1: Initialize the Git Repository. Go to the command prompt, go to your project
folder and issue the command git init. This command will add the necessary Git files to
the project folder, so that it can be recognized by Git when it needs to be uploaded to the
repository.

56
 Continuous Integration

Step 2: Adding your files which need to be added to the Git repository. This can be done
by issuing the git add command. The dot option tells Git that all files in the project folder
need to be added to the Git repository.

Step 3: The final step is to commit the project files to the Git repository. This step is
required to ensure all files are now a part of Git. The command to be issued is given in the
following screenshot. The –m option is to provide a comment to the upload of files.

Your solution is now available in Git.

57
 5. CI – Features Continuous Integration

Following are some of the main features or practices for Continuous Integration.

 Maintain a single source repository – All source code is maintained in a single

repository. This avoids having source code being scattered across multiple
locations. Tools such as Subversion and Git are the most popular tools for
maintaining source code.

 Automate the build – The build of the software should be carried out in such a
way that it can be automated. If there are multiple steps that need to be carried
out, then the build tool needs to be capable of doing this. For .Net, MSBuild is the
default build tool and for Java based applications you have tools such as Maven
and Grunt.

 Make your build self-testing – The build should be testable. Directly after the
build occurs, test cases should be run to ensure that testing can be carried out for
the various functionality of the software.

 Every commit should build on an integration machine – The integration

machine is the build server and it should be ensured that the build runs on this
machine. This means that all dependent components should exist on the
Continuous Integration server.

 Keep the build fast – The build should happen in minutes. The build should not
take hours to happen, because this would mean the build steps are not properly
configured.

 Test in a clone of the production environment – The build environment should

be close in nature to the production environment. If there are vast differences
between these environments, then there can be a case that the build may fail in
production even though it passes on the build server.

 Everyone can see what is happening – The entire process of build and testing
and deployment should be visible to all.

 Automate deployment – Continuous Integration leads to Continuous

deployment. It is absolutely necessary to ensure that the build should be easy to
deploy onto either a staging or production environment.

58
 6. CI – Requirements Continuous Integration

Following is the list of the most significant requirements for Continuous Integration.

 Check-In Regularly – The most important practice for continuous integration to

work properly is frequent check-ins to trunk or mainline of the source code
repository. The check-in of code should happen at least a couple of times a day.
Checking in regularly brings lots of other benefits. It makes changes smaller and
thus less likely to break the build. It means the recent most version of the software
to revert to is known when a mistake is made in any subsequent build.

It also helps to be more disciplined about refactoring code and to stick to small
changes that preserve behavior. It helps to ensure that changes altering a lot of
files are less likely to conflict with other people’s work. It allows the developers to
be more explorative, trying out ideas and discarding them by reverting back to the
last committed version.

 Create a Comprehensive Automated Test Suite – If you don’t have a

comprehensive suite of automated tests, a passing build only means that the
application could be compiled and assembled. While for some teams this is a big
step, it’s essential to have some level of automated testing to provide confidence
that your application is actually working.

Normally, there are 3 types of tests conducted in Continuous Integration namely

unit tests, component tests, and acceptance tests.

Unit tests are written to test the behavior of small pieces of your application in
isolation. They can usually be run without starting the whole application. They do
not hit the database (if your application has one), the filesystem, or the network.
They don’t require your application to be running in a production-like environment.
Unit tests should run very fast — your whole suite, even for a large application,
should be able to run in under ten minutes.

Component tests test the behavior of several components of your application. Like
unit tests, they don’t always require starting the whole application. However, they
may hit the database, the filesystem, or other systems (which may be stubbed
out). Component tests typically take longer to run.

 Keep the Build and Test Process Short - If it takes too long to build the code
and run the unit tests, you will run into the following problems –

o People will stop doing a full build and will run the tests before they check-
in. You will start to get more failing builds.

o The Continuous Integration process will take so long that multiple commits
would have taken place by the time you can run the build again, so you
won’t know which check-in broke the build.

o People will check-in less often because they have to sit around for ages
waiting for the software to build and the tests to run.

59
 Continuous Integration

 Don’t Check-In on a Broken Build – The biggest blunder of continuous

integration is checking in on a broken build. If the build breaks, the developers
responsible are waiting to fix it. They identify the cause of the breakage as soon as
possible and fix it. If we adopt this strategy, we will always be in the best position
to work out what caused the breakage and fix it immediately.

If one of our colleagues has made a check-in and has as a result broken the build,
then to have the best chance of fixing it, they will need a clear run at the problem.
When this rule is broken, it inevitably takes much longer for the build to be fixed.
People get used to seeing the build broken, and very quickly you get into a situation
where the build stays broken all of the time.

 Always Run All Commit Tests Locally Before Committing – Always ensure
that the tests designed for the application are run first on a local machine before
running them on the CI server. This is to ensure the right test cases are written
and if there is any failure in the CI process, it is because of the failed test results.

 Take Responsibility for All Breakages that Result from Your Changes – If
you commit a change and all the tests you wrote pass, but others break, the build
is still broken. Usually this means that you have introduced a regression bug into
the application. It is your responsibility — because you made the change — to fix
all tests that are not passing as a result of your changes. In the context of CI this
seems obvious, but actually it is not a common practice in many projects.

60
 7. CI – Building a Solution Continuous Integration

There are a variety of build tools available for a variety of programming languages. Some
of the most popular build tools include Ant for Java and MSBuild for .NET. Using a
scripting tool designed specifically for building software, instead of a custom set of shell
or batch scripts, is the most effective manner for developing a consistent, repeatable build
solution.

So why do we need a build process to start with. Well for starters, for a Continuous
Integration server, the build process should be easy to work with and should be seamless
to implement.

Let’s take a simple example of what a build file can look like for .Net –

<?xml version="1.0" encoding="utf-8"?>

<project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text ="Building Project" />
<MSBuild Projects="project.csproj" Targets="Build/>"
</Target>
</project>

The following aspects need to be noted about the above code –

 A target is specified with a name of the Build. Wherein, a target is a collection of

logical steps which need to be performed in a build process. You can have multiple
targets and have dependencies between targets.

 In our target, we keep an option message which will be shown when the build
process starts.

 The MSBuild task is used to specify which .Net project needs to be built.

The above example is a case of a very simple build file. In Continuous Integration, it is
ensured that this file is kept up-to-date to ensure that the entire build process is seamless.

Building a Solution in .Net

The default build tool for .Net is MSBuild and is something that comes shipped with the
.Net framework. Depending on the framework on your system, you will have the relevant
MSbuild version available. As an example, if you have the .Net framework installed in the
default location, you will find the MSBuild.exe file in the following location –

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Let’s see how we can go about building our sample project. Let’s assume our Sample
project is located in a folder called C:\Demo\Simple.

61
 Continuous Integration

In order to use MSBuild to build the above solution, we need to open the command prompt
and use the MSBuild option as shown in the following program.

msbuild C:\Demo\Simple\Simple.csproj

In the above example, csproj is the project file which is specific to .Net. The csproj file
contains all the relevant information to ensure that the required information is present for
the software to build properly. Following is the screenshot of the output of the MSBuild
command.

You don’t need to worry about the output warnings as long as the Build was successful
and there were no errors.

62
 8. CI – Build Scripts Continuous Integration

Now let’s look at certain aspects of the MSBuild file to see what they mean. These aspects
are important to know from a Continuous Integration Cycle.

Build scripts are used to build the solution which will be a part of the entire continuous
Integration cycle. Let’s look at the general build script which is created as a part of Visual
Studio in .Net for our sample solution. The build script is a pretty big one, even for a
simple solution, so we will go through the most important parts of it. By default, the build
script will be stored in a file with the same name as the main solution in Visual Studio. So
in our case, if you open the file Simple.csproj, you will see all the settings which will be
used to build the solution.

 Dependency on the MSBuild version used – The following settings will use the
MSBuild files installed on the CI server.

<VisualStudioVersion Condition="'$(VisualStudioVersion)' ==
''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' ==
''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</
VSToolsPath>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import
Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets"
Condition="'$(VSToolsPath)' != ''" />
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplication
s\Microsoft.WebApplication.targets" Condition="false" />

 What files are required to build the solution properly – The ItemGroup tag will
contain all the necessary .Net files which are required for the project to build
successfully. These files will need to reside on the build server accordingly.

<ItemGroup>
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Web.DynamicData" />
<Reference Include="System.Web.Entity" />
<Reference Include="System.Web.ApplicationServices" />
<Reference Include="System.ComponentModel.DataAnnotations" />
<Reference Include="System" />
<Reference Include="System.Data" />
<Reference Include="System.Core" />

63
 Continuous Integration

<Reference Include="System.Data.DataSetExtensions" />

<Reference Include="System.Web.Extensions" />
<Reference Include="System.Xml.Linq" />
<Reference Include="System.Drawing" />
<Reference Include="System.Web" />
<Reference Include="System.Xml" />
<Reference Include="System.Configuration" />
<Reference Include="System.Web.Services" />
<Reference Include="System.EnterpriseServices" />
</ItemGroup>

 What are the Web server settings to be used – When we visit our topic of
Continuous Deployment, you will see how MSBuild will be used to override these
settings and deploy this to our server of choice.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:59495/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

64
 9. CI – Building on the Server Continuous Integration

The next important step is to ensure that the solution builds on the build server. The first
part is a manual step, because before the continuous integration tool is used, we first must
ensure that the build gets run on the build server in the same manner as what was done
on the client machine. To do this, we must implement the following steps:

Step 1: Copy the entire solution file to the server. We had created an Amazon instance
server which would be used as our build server. So, do a manual copy to the server of the
entire .Net solution onto the server.

65
 Continuous Integration

Step 2: Ensure that the framework is present on the server. If you have compiled your
application in .Net framework 4.0 on your client machine, you have to ensure that it is
installed on the server machine as well. So go to the location
C:\Windows\Microsoft.NET\Framework on your server and ensure the desired
framework is present.

Step 3: Now let’s just run MSBuild on the server and see what happens.

66
 Continuous Integration

Ok, so it looks like we have hit an error. There is one important lesson in Continuous
Integration and that is you need to ensure that the Build works on the build server. For
this you need to ensure that all prerequisite software is installed on the build server.

For .Net, we need to install a component called Visual Studio Redistributable package.
This package contains all the necessary files which are required for a .Net application to
build on a server. So let’s carry out the following installation steps on the build server.

Step 4: Double-click the executable file to start the installation.

67
 Continuous Integration

Step 5: In the next step, agree to the License Terms and click Install.

68
 Continuous Integration

Step 6: Now when running MSBuild, we need to ensure that we include an additional
parameter when calling MSBuild which is – p:VisualStudioversion=12.0. This ensures
that MSBuild references those files that were downloaded in the earlier step.

Now we can see that the solution has been built properly and we also know our baseline
project builds correctly on the server.

69
 10. CI – Checking in Source Code Continuous Integration

The next key aspect is to ensure our baseline code is checked into our source code
repository management server which is Git. To do this, we need to follow these steps:

Step 1: Initialize the repository so that it can be uploaded to Git. This is done with the git
init command. So you need to go to your project folder and issue the git init command.

Step 2: The next step is called staging files in Git. This prepares all the files in the project
folder, which need to be added to Git. You do this with the git add command as shown in
the following screenshot. The ‘.’ notation is used to say that all files in the directory and
subdirectory should be included in the commit.

70
 Continuous Integration

Step 3: The final step is to commit the files to the Git repository, so that it is now a full-
fledged Git repository.

71
 11. CI – Creating a Project in TeamCity Continuous Integration

Now that we have our source code in the Git repository and all of our initial code works on
the build server, it is time to create a project in our Continuous Integration server. This
can be done via the following steps:

Step 1: Login to the TeamCity software. Go to the url on your Continuous Integration
server – http://localhost:8080/login.html

Enter the admin credentials and login to the server.

72
 Continuous Integration

Step 2: Once logged in, you will be presented with the home screen. Click Create Project
to start a new project.

73
 Continuous Integration

Step 3: Give a name for the project and click Create to start the project. In our case, we
are giving the name as ‘Demo’ to our project as shown in the following screenshot.

74
 Continuous Integration

Step 4: The next step is to mention the Git repository which will be used in our project.
Remember that in a Continuous Integration environment, the CI server needs to pick up
the code from the Git enabled repository. We have already enabled our project folder to
be a Git enabled repository in the earlier step. In TeamCity, you need to create a VCS
root. For this, click VCS Roots in the project’s main screen.

75
 Continuous Integration

Step 5: In the screen that comes up next, click Create VCS root as shown in the following
screenshot.

76
 Continuous Integration

Step 6: In the next screen that comes up, perform the following steps:

 Mention the type of VCS as Git.

 Give a name for the VCS root, this can be any friendly name. We have given the
name as App.

 Give the Fetch url as C:\Demo\Simple – This is out git enabled repository.

 If you scroll down the screen, you will get a Test connection button. Click it to
ensure that you can successfully connect to the Git enabled repository.

77
 Continuous Integration

Step 7: Click Create and you will now see your repository registered as shown in the
following image.

78
Continuous Integration

79
 Continuous Integration

Step 8: The next step is to create a build configuration which will be used to build the
project. Go to your project screen in TeamCity -> General Settings. Click Create Build
Configuration.

80
 Continuous Integration

Step 9: In the following screen, give a name for the Build Configuration. In our case we
have named it as DemoBuild and then click Create.

81
 Continuous Integration

Step 10: In the next screen that comes up, you will be asked to choose the VCS
repository which was created in the earlier steps. So choose the name ‘App’ and click
Attach.

Step 11: Now in the next screen that pops up, we need to configure the build steps. So
click the ‘configure build steps manually’ hyperlink.

82
 Continuous Integration

Step 12: In the next build screen, we need to enter the following details:

 Choose the Runner type as MSBuild.

 Give an optional name for the step name.

 Give the name of the file which needs to be built. When we specify MSbuild in the
earlier sections, we normally see that we give the option of Simple.csproj. The
same thing is needed to be specified here.

 Choose the MSBuild version as ‘Microsoft Build Tools 2013’.

 Choose the MSBuild ToolsVersion as 12.0.

 Scroll down the page to Save the settings.

83
 Continuous Integration

Step 13: In the next screen, click Run.

You will see the build of your application now in progress.

84
 Continuous Integration

You should get a successful screen, which is a good sign that your solution is building
properly.

85
 Continuous Integration

You can also go to your build log to see all the steps that were covered by the Continuous
Integration server as shown in the following screenshot.

86
 12. CI – Defining Tasks Continuous Integration

Now that we have our base code in Git and a link to the Continuous Integration server, its
finally time to see the first step of Continuous Integration in action. This is done by defining
tasks in the Continuous Integration server such as triggers, which makes the entire
Continuous Integration Process as seamless as possible. Let’s make a change to our code
in Visual Studio.

Step 1: Go to the Demo.aspx page in Visual Studio and make a change to the title of the
page.

87
 Continuous Integration

Step 2: If we query our Git repository via the git status command, you will in fact see
that the Demo.aspx file has been modified.

Now we need to ensure that every change in our code should trigger a build in our
continuous integration server. For this we need to do the following changes.

Step 3: Go to your project dashboard and click the triggers section and click Add new
trigger.

88
 Continuous Integration

Step 4: In the next screen that comes up, choose VCS trigger, which will be used to
create a trigger so that when a check-in is made to the repository, a build will be triggered.

Step 5: Click Show Advanced Options and ensure the options shown in the following
screenshot are selected.

Step 6: Click Save. You will now see the trigger successfully registered as shown in the
following screenshot.

89
 Continuous Integration

Step 7: Now it’s time to check in our code into the Git repository and see what happens.
So let’s go to our command prompt and issue the git add command to stage our changed
files.

Step 8: Now issue the git commit command, and it will push the changes into the Git
repository.

90
 Continuous Integration

Step 9: If you now go to your Projects Overview screen, you will now see a new build
would have been triggered and run.

91
 Continuous Integration

If you see the Change log Tab, you will see the git comment which triggered the build.

Let’s try it one more time. Let’s make another change to the Demo.aspx file. Let’s carry
out a git add command and a git commit command with the following commit message.

92
 Continuous Integration

You will now see a build being automatically triggered in the Project dashboard in
TeamCity.

93
 Continuous Integration

The build will show a success message.

You will now see the message of ‘Second commit’ which was used when the change was
committed to the git repository.

We have now successfully completed the first part of the Continuous Integration process.

94
 13. CI – Build Failure Notifications Continuous Integration

A Build Failure Notification is an event which is triggered whenever a build fails. The
notification is sent to all key people whenever a build fails. The first important thing to do
in such a case is to ensure time is spent on the failed build to ensure the build passed. The
following steps are used to ensure that the build notifications are put in place in TeamCity.

Following are the steps to set up email notifications in TeamCity.

Step 1: In TeamCity, go to your Project dashboard, click on Administration in the top right
hand corner. You will then see the Email Notifier link in the left hand side. Click on this
link to bring up the general settings for Email.

Step 2: Next step is to enter the details of a valid SMTP Server. Gmail provides a free
SMTP facility, which can be used by anyone. So we can enter those details in the next
screen that comes up as shown in the following screenshot.

 SMTP Host – smtp.gmail.com

 SMTP port no – 465

95
 Continuous Integration

 Send email messages from and SMTP login – This should be a valid Gmail id

 SMTP password – Valid password for that Gmail id

 Secure connection – Put this as SSL

Step 3: Click Test Connection just to ensure that the settings are working properly.
Then click Save to save the settings.

96
 Continuous Integration

Step 4: The next step is to enable build notifications for a user. The first task is to create
a user which will receive these build notifications. Go to your project dashboard and choose
the Users Option.

97
 Continuous Integration

Step 5: Create a new user. Enter the required username and password. Then Click the
Create User button, which will be located at the bottom of the screen.

98
 Continuous Integration

Step 6: Now login to the TeamCity system with this new user id and password.

99
 Continuous Integration

Step 7: After you log in, you will be presented with the General settings of the user. In
the Email Notifier section, click Edit.

100
 Continuous Integration

Step 8: In the next screen that comes up, click Add new rule.

101
 Continuous Integration

Step 9: In Add new rule, choose the following two options and then click Save.

 Builds from select projects – Choose the Demo project.

 Enable the checkbox for ‘Build fails’.

By enabling these two options, now whenever a build fails for the Demo project, an email
notification will be sent to the user – demouser.

102
 Continuous Integration

Step 10: Now let’s trigger a wrong build to see this in action. In Visual Studio, go to the
demo.aspx.cs file and add a wrong line of code.

Step 11: Now check-in the code from Git by doing a git add and git commit.

103
 Continuous Integration

Now in the Project Dashboard, the build will automatically be triggered and you will see
that the build would have failed as shown in the following screenshot.

104
 Continuous Integration

If you login into the Gmail id of the demouser, you will actually see a build failure
notification in it as shown in the following screenshot.

105
 14. CI – Documentation and Feedback Continuous Integration

One of the key aspects of Continuous Integration is always to see how the builds are
performing, gathering important metrics, documenting those outcomes and generating
continuous feedback through continuous builds.

What are the benefits of having these metrics in place?

 Not Committing Code Enough – If developers are not committing code to a

version control repository frequently, the reason may be a slow integration build.
To begin to reduce build duration, perform a high-level analysis of the integration
build environment to determine the bottlenecks.

Next, analyze the findings and determine the most appropriate improvement, then
attempt to make changes in the build process to reduce the build’s duration. Lastly,
reevaluate the build duration to determine if further improvements are warranted.

 Improve Test Performance – Even in a well-functioning CI system, a bulk of the

integration build time will be taken up by the execution of automated tests.
Evaluating and improving the performance of these tests can dramatically reduce
build duration.

 Infrastructure Issues – You may discover that integration builds are slow
because of the system infrastructure. Perhaps network performance is slow or there
is a slow-performing virtual private network connection.

Geographically dispersed systems and unreliable hardware or software can also

induce performance issues. Investigate and improve any infrastructure resources
to reduce the build duration.

Metrics
Following are some of the metrics which are available in a Continuous Integration server.

Let’s look at what TeamCity has to offer:

One of the simplest form of metrics is what is available in the project dashboard. The key
element here is to note the duration of each build. If the duration of each build starts
increasing disproportionally to the code being built, then this could be an issue. So, this is
one feedback that can be taken and the causes of this could be that the CI server is low
on resources and maybe the capacity of the server needs to be increased.

106
Continuous Integration

107
 Continuous Integration

TeamCity has the facility to see if the CI server is in fact having any sort of issues with
regards to infrastructure. In the admin dashboard in TeamCity, one can click on Disk
Usage to see how much disk space is being consumed by each build.

108
 Continuous Integration

If any more details are required, then TeamCity has the diagnostics button, which can
give more information on the CPU and Memory being utilized by the CI Server.

109
 Continuous Integration

Detailed View of Build Metrics

If one wants to see a detailed view of the builds of a particular project over time, then this
is available as a part of the project builds. In the Project build screen, go to the Statistics
screen, this will provide various statistics and charts on how the build is performing.

110
 15. CI – Continuous Testing Continuous Integration

One of the key features of Continuous Integration is to ensure that the on-going testing
holds all the code which gets built by the CI server. After a build is carried out by the CI
Server, it has to be ensured that the test cases are in place to get the required code tested.
Every CI server has the ability to run unit test cases as part of the CI suite. In .Net, the
unit testing is a feature which is inbuilt into the .Net framework and the same thing can
be incorporated into the CI Server as well.

This chapter will see how we can define a test case in .Net and then let our TeamCity
server run this test case after the build is completed. For this, we first need to ensure that
we have a unit test defined for our sample project.

To do this, we must follow the ensuing steps with utmost carefulness.

Step 1: Let’s add a new class to our solution, which will be used in our Unit Test. This
class will have a name variable, which will hold the string “Continuous Integration”. This
string will be displayed on the web page. Right-click on the Simple Project and choose the
menu option Add -> Class.

111
 Continuous Integration

Step 2: Give a name for the class as Tutorial.cs and click the Add button at the bottom
of the screen.

Step 3: Open the Tutorial.cs file and add the following code in it. This code just creates a
string called Name, and in the Constructor assign the name to a string value as
Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple
{
public class Tutorial
{
public String Name;
public Tutorial()
{
Name = "Continuous Integration";

112
 Continuous Integration

}
}
}

Step 4: Let us make the change to our Demo.aspx.cs file to use this new class. Update
the code in this file with the following code. So this code will now create a new instance of
the class created above.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple
{

public partial class Demo : System.Web.UI.Page

{
Tutorial tp = new Tutorial();

protected void Page_Load(object sender, EventArgs e)

{

tp.Name = "Continuous Integration";

}
}
}

Step 5: In our demo.aspx file, let us now reference the tp.Name variable, which was
created in the aspx.cs file.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Demo.aspx.cs"

Inherits="Simple.Demo" %>

<!DOCTYPE html>

113
 Continuous Integration

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>TutorialsPoint1</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<%=tp.Name%>)

</div>
</form>
</body>
</html>

Just to ensure our code works fine with these changes, you can run the code in Visual
Studio. You should get the following output once the compilation is complete.

114
 Continuous Integration

Step 6: Now it is time to add our Unit tests to the project. Right-click on Solution and
choose the menu option Add -> New Project.

Step 7: Navigate to Test and on the right hand side, choose Unit Test Project. Give a
name as DemoTest and then click OK.

115
 Continuous Integration

Step 8: In your Demo Test project, you need to add a reference to the Simple project
and to the necessary testing assemblies. Right-click on the project and choose the menu
option Add Reference.

116
 Continuous Integration

Step 9: In the next screen that comes up, go to Projects, choose Simple Reference and
click OK.

117
 Continuous Integration

Step 10: Click Add Reference again, go to Assemblies and type Web in the Search box.
Then add a reference of System.Web.

Step 11: In the Unit Test file, add the following code. This code will ensure that the
Tutorial class has a string name variable. It will also assert the fact that the Name should
equal a value of “Continuous Integration”. This will be our simple Test case.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest
{
[TestClass]
public class UnitTest1
{

118
 Continuous Integration

[TestMethod]
public void TestMethod1()
{

Tutorial tp = new Tutorial();

Assert.AreEqual(tp.Name, "Continuous Integration");

}
}
}

Step 12: Now let’s run our test in Visual Studio to make sure it works. In Visual Studio,
choose the menu option Test -> Run -> All Tests.

119
 Continuous Integration

After running the test, you will see the Test successfully run on the left hand side of Visual
Studio.

120
 Continuous Integration

Enabling Continuous Testing within TeamCity – Now that all the test cases are in place, it
is time to integrate these into our Team City server.

Step 13: For this, we need to create a build step in our Project configuration. Go to your
project home and click Edit Configuration Settings.

121
 Continuous Integration

Step 14: Then go to Build Step -> MS Build and click Add build step as depicted in the
following screenshot.

In the next screen that comes up, add the following values –

 Choose the runner type as Visual Studio Tests.

 Enter an optional Test step name.

 Choose the Test Engine type as VSTest.

 Choose the Test Engine version as VSTest2013.

 In the Test files name, provide the location as

DemoTest\bin\Debug\DemoTest.dll – Remember that DemoTest is the name
of our project which contains our Unit Tests. The DemoTest .dll will be generated
by our first build step.

 Click Save which will be available at the end of the screen.

122
Continuous Integration

123
 Continuous Integration

Now you will have 2 build steps for your project. The first is the Build step which will build
your application code and your test project. And the next will be used to run your test
cases.

Step 15: Now it is time to check-in all your code in Git, so that the entire build process
can be triggered. The only difference is this time, you need to run the git add and git
commit command from the Demo parent folder as shown in the following screenshot.

124
 Continuous Integration

Now when the build is triggered, you will see an initial output which will say that the test
passed.

Step 16: If you click on the Test passed result and go to the Test tab, you will now see
that the UnitTest1 was executed and that it is passed.

125
 16. CI – Continuous Inspection Continuous Integration

Continuous Inspection is the process of an automated code review of inspection conducted

for your code before the actual tests are run. There are subtle differences between
inspecting and testing software. Testing is dynamic and executes the software in order to
test the functionality. Inspection analyzes the code based on a set of predefined rules.

Inspectors (or static and dynamic analysis tools) are directed by identified standards that
teams should adhere to (usually coding or design metrics). Examples of inspection targets
include coding “grammar” standards, architectural layering adherence, code duplication,
and many others.

Continuous Inspection reduces the time between a discovery and a fix. There are a number
of Continuous Inspection tools available. For this example, we are going to be using
NCover 3.x which has an integration with TeamCity. Let’s see how we can carry out
Continuous Inspection and what it can do for us.

Download and Install NCover

NCover is a separate product which needs to be downloaded and installed. To Download
NCover, please click on the following link and download the 32-bit installer –
http://www.ncover.com/info/download

126
 Continuous Integration

Run the downloaded installer and then click Next after the installer is started.

Accept the License agreement and then click Next.

127
 Continuous Integration

Accept the default components and click Next.

128
 Continuous Integration

Click on the Install button to begin the installation.

Click the Finish button to complete the installation.

129
 Continuous Integration

Launch the NCover installation for the first time by going to C:\Program Files
(x86)\NCover\ NCover.Explorer.exe. You will just need to install a trial key for the
first time, which is a straightforward process.

130
 Continuous Integration

Configure the Project in TeamCity to Use NCover

Step 1: Go to your project home screen and click Edit Configuration Settings.

131
 Continuous Integration

Step 2: Go to Build Steps and click Edit for the TestStep. Continuous Inspection needs
to run along with the Unit tests which are defined.

Step 3: In the .Net Coverage section, click on .Net Coverage Tool. And then choose the
following settings –

 Choose the .Net Coverage tool as NCover(3.x)

 Platform as x86

 Version as v4.0

 Path to NCover as C:\Program Files (x86)\NCover

 Leave the other settings as they are

Step 4: Click Save.

132
Continuous Integration

133
Continuous Integration

134
 Continuous Integration

Step 5: Now go to the main screen of your project and click Run.

135
Continuous Integration

136
 Continuous Integration

Step 6: Once the build is run, click on the Test passed. You will now see a Code Coverage
screen and you will see many metric indicators.

Step 7: You can now click the Code Coverage tab to get more information on the Code
Analysis.

137
 Continuous Integration

Step 8: Click the fullcoveragereport.html. You will now get a full comprehensive report
on the inspection carried out for the .Net code.

138
17. CI – Continuous Database Integration Continuous Integration

Continuous Database Integration is the process of rebuilding your database and test data
any time a change is applied to a project’s version control repository.

In Database Integration, generally all the artifacts related to the database integration –

 Should reside in a version control system.

 Can be tested for rigor and inspected for policy compliance.

 Can be generated using your build scripts.

Activities that can be involved in Continuous Database Integration can be any one of the
following –

 Drop a Database – Drop the database and remove the associated data, so that
you can create a new database with the same name.

 Create a new Database – Create a new database using Data Definition Language
(DDL).

 Insert the Initial Data – Insert any initial data (e.g., lookup tables) that your
system is expected to contain when delivered.

 Migrate Database and Data – Migrate the database schema and data on a
periodic basis (if you are creating a system based on an existing database).

 Modify Column Attributes – Modify table column attributes and constraints based
on requirements and refactoring.

 Modify Test Data – Alter test data as needed for multiple environments.

So in our Continuous Database example, we are going to do the following steps –

 We will create a MS SQL Server database and a corresponding table.

 We will create a script out of SQL Server Management Studio. This database script
will be used to set up our table in the database.

 We will write a code in our ASP.Net project to access this database.

 We will create a step in our project in TeamCity to run this script.

 We will check in our script into Git.

Steps to do this in the AWS database which was created in an earlier section.

139
 Continuous Integration

Step 1: Create an MS SQL Server database and a corresponding table. Let’s open SQL
Server Management Studio and create a simple database and table. Right-click databases
and click on New Database.

140
 Continuous Integration

Step 2: Name it as Demodb and click OK.

141
 Continuous Integration

Step 3: In the new database, right-click and create a new table.

142
 Continuous Integration

Step 4: You can add your desired columns to the table.

Step 5: Save the table and name it as Demotb.

143
 Continuous Integration

Step 6: Now right-click on the table and choose the menu option Script Table as ->
Drop and Create to -> File.

144
 Continuous Integration

Step 7: Save the file to the demo project folder as Sample.sql.

This is what the database script would look like. It would first drop an existing table if
present and then re-create the table.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]

GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON

145
 Continuous Integration

GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](

[TutorialName] [nvarchar](max) NULL,
[TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8: Now let’s quickly change our ASP.Net code to refer to the new database.

Step 9: In the Tutorial.cs file in your Demo project, add the following lines of code.
These lines of code will connect to your database, take the Server version and store the
version name in the Name variable. We can display this Name variable in our
Demo.aspx.cs file through a Response.write command.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple
{
public class Tutorial
{
public String Name;
public Tutorial()
{
string connectionString = "Data Source=WIN-50GP30FGO75;Initial
Catalog=Demodb;Integrated Security=true;";

using (SqlConnection connection = new SqlConnection())

{
connection.ConnectionString = connectionString;

146
 Continuous Integration

connection.Open();
Name = connection.ServerVersion;
connection.Close();
}

}
}
}

Step 10: Add the following code to the Demo.aspx.cs file to ensure that it displays the
SQL Server version.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple
{

public partial class Demo : System.Web.UI.Page

{
Tutorial tp = new Tutorial();

protected void Page_Load(object sender, EventArgs e)

{
Response.Write(tp.Name);

}
}
}

147
 Continuous Integration

Now if we run the code, you will get the following output in the browser.

Step 11: Now let us add our step in TeamCity which will invoke the database script. Go
to your project dashboard and click Edit Configuration Settings.

148
 Continuous Integration

Step 12: Go to Build Steps and click Add build step.

Choose the following options (Note that MS SQL Server client should be installed on the
CI Server).

 Runner type should be the Command Line.

 Give an optional Step Name.

 Run should be Executable with parameters.

 Command executable should be C:\Program Files\Microsoft SQL

Server\110\Tools\Binn\sqlcmd.exe

 Command parameters should be -S WIN-50GP30FGO75 -i Sample.sql. Where

–S gives the name of the SQL Server instance.

Step 13: Click Save.

149
 Continuous Integration

Now what needs to be ensured is the build order. You have to ensure the build order is as
follows.

Step 14: You can change the build order by choosing the option to reorder build steps.

 The database setup should be first – So this will be used to recreate your database
from fresh.

 Next is the build of your application.

 Finally your test setup.

150
 Continuous Integration

Step 15: Now run the git add and git commit command so that the Sample.sql file is
checked into Git. This will trigger a build automatically. And this build should pass.

You now have a full-fledged build cycle with a continuous database integration aspect as
well in your cycle. In the next section, let’s take this further and look at Continuous
Deployment.

Now that you have done this with a local SQL Server, we can repeat the same steps for a
AWS MS SQL Server which was created in one of the earlier sections. To connect to a
Microsoft SQL Server, you need to connect via the following convention.

Step 16: First see what is the name assigned to your database instance in AWS. When
you log-in to the AWS, go to the RDS section under the database section.

151
Continuous Integration

152
 Continuous Integration

Step 17: Click on DB Instances in the next screen that comes up.

153
 Continuous Integration

Step 18: Click on your database and make a note of the endpoint. In the following
screenshot, it is demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

154
 Continuous Integration

Step 19: Now to connect to the database from SQL Server Management Studio, you
need to specify the connection as demodb.cypphcv1d87e.ap-southeast-
1.rds.amazonaws.com,1433 (Note the comma used between instance name and port
no)

The following screenshot shows a successful connection to the database.

155
 Continuous Integration

Then you can repeat all the same steps. The Sqlcmd command will be as follows:

This same command can be replaced in the Database build step in TeamCity. When you
execute the sqlcmd command, the table will be created automatically in your SQL Server
database in AWS.

156
 18. CI – Continuous Deployment Continuous Integration

Automated builds and repeatable builds. Automated tests and repeatable tests. Test
categories and test frequencies. Continuous inspections. Continuous database integration.
These string of tasks in creating an effective CI environment primarily enables one key
benefit: releasing working software at any point in time, in any environment.

In our previous chapters, we have accomplished all of the following segments:

 Created our code.

 Ensured a proper build in TeamCity.

 Created a Database Integration process.

 Conducted successful testing.

Now the only thing remaining is to carry out an automated deployment, so that our entire
process is complete.

For an automated deployment in our case, we need to follow these steps:

 In our deployment server, ensure that IIS is installed.

 Ensure that IIS user is given access to our database.

 Create a publish profile which will be used to publish the site when it is built.

 Ensure we change our MSBuild command to do an automatic deployment.

 Automate TeamCity to do an automatic publish.

 Do a git commit to ensure all your files are in Git.

Step 1: Configure a local IIS Server. If you have a local or remote IIS Server, the following
configuration can be carried out to deploy our application. It’s always a good practice to
see if a deployment can be done manually before it is done in an automated fashion.

Step 2: On a Windows 2012 server, go to your Server Manager and click on Add Roles
and Features.

157
 Continuous Integration

Step 3: Click Next on the following screen that comes up.

158
 Continuous Integration

Step 4: Choose roles-based or feature-based installation on the next screen and click
Next.

159
Continuous Integration

160
 Continuous Integration

Step 5: Select the default server and click Next.

161
 Continuous Integration

Step 6: Choose the Web server role and click Next.

162
 Continuous Integration

Step 7: In the next screen that comes up, click Next.

163
 Continuous Integration

Step 8: Click Next again on the following screen that appears.

164
 Continuous Integration

Step 9: In the next screen that pops up, click Next.

165
 Continuous Integration

Step 10: In the final screen, you can click the Install button to install the IIS.

166
 Continuous Integration

Once you have IIS installed, you can open it by opening the Internet Information Services.

Step 11: Click Application Pools, you will see a pool with the name of DefaultAppPool.
This needs to have access to SQL Server in the next step.

Step 12: If we need to connect a ASP.Net application to a MS SQL Server application, we

have to give access to the default application pool to the SQL Server instance, so that it
can connect to our Demodb database.

167
 Continuous Integration

Step 13: Open SQL Server Management Studio. Go to Logins, right-click and choose the
menu option New Login.

168
 Continuous Integration

In the next screen, update the following parameters and click OK.

 Login name as IIS APPPOOL\DefaultAppPool.

 Default database – This should be our database, which is demodb.

169
 Continuous Integration

Step 14: Creating a Publish Profile. The publish profile is used in Visual Studio to create
a deployment package that can then be used with MS Build and in any CI Server
accordingly. To do this, from Visual Studio, right-click on the project and click the menu
option of Publish.

170
 Continuous Integration

Step 15: In the next screen that comes up, choose to create a new Publish profile, give
it a name – DemoDeployment. Then click the Next button.

171
 Continuous Integration

In the ensuing screen that shows up, add the following values:

 Choose the Publish method as Web Deploy.

 Enter the server as localhost.

 Enter the site name as Default Web Site/Demo.

 Put the destination url as http://localhost/Demo

Then click the Next button.

172
 Continuous Integration

Step 16: In the next screen, click Next.

173
 Continuous Integration

Step 17: In the final screen that comes up, click the Publish button.

Now if you go to the C:\Demo\Simple\Properties\PublishProfiles location of your

project, you will see a new publish profile xml file created. This publish profile file will
have all the details required to publish your application to the local IIS server.

Step 18: Now let’s customize our MSBuild command and use the above publish profile
and see what happens. In our MSBuild command, we specify the following parameters:

 Deploy on Build is true – this will trigger an automatic deployment once a successful
build is done.

 We are then mentioning to use the Publish profile which was used in the above
step.

 The Visual Studio version is just to be mentioned to the MSBuild deployment

capability on what is the version of the Visual Studio being used.

174
 Continuous Integration

When you run the above command, MSBuild will trigger a build and deployment process.
What you will note that, it is deploying it to our Default Website in our IIS Server.

175
 Continuous Integration

Now if we browse to the site – http://localhost/Demo/Demo.aspx we will see the following

output, which means that the MSBuild did a successful deployment to our website.

Step 19: Automating through TeamCity – Now it is time to add a task to our TeamCity
server to automatically use MSBuild to deploy our application, based on the above
mentioned steps.

Step 20: Go to your project dashboard and click Edit Configuration Settings.

176
 Continuous Integration

Step 21: Go to Build Steps and click Add a Build step.

177
 Continuous Integration

Choose the following options –

 The runner type should be MSBuild

 Give an optional Step name

 Enter the build path as Simple/Simple.csproj

 Keep the MSBuild version as Microsoft Build Tools 2013

 Keep the MSBuild Toolsversion as 12.0

 Put the command line as /p:DeployOnBuild=true

/p:PublishProfile=DemoDeployement /p:VisualStudioVersion=12.0

Step 22: Click Save.

178
Continuous Integration

179
 Continuous Integration

Make sure that in the build steps, the Deploy step is the last step in the chain.

180
 Continuous Integration

Step 23: Now let’s do a final git commit, to ensure all the files are in Git and can be used
by TeamCity.

Congratulations, you have successfully set up a complete Continuous Integration Cycle for
your application, which can be run at any point in time.

181
 19. CI – Best Practices Continuous Integration

Let’s have a final review of the best practices of Continuous Integration based on all the
lessons we have learnt so far –

 Maintain a code repository – This is the most basic step. In all our examples,
everything is maintained in a Git repository right from the code base to the Publish
profiles, to the database scripts. It must always be ensured that everything is kept
in the code repository.

 Automate the build – We have seen how to use MSBuild to automate a build
along with using a publish profile. This is again a key step in the continuous
Integration process.

 Make the build self-testing – Ensure that you can test the build by keeping unit
test cases in place and these test cases should be in such a way that it can be run
by the Continuous Integration server.

 Everyone commits to the baseline every day – This is a key principle of

Continuous Integration. There is no point staying till the end of the entire process
to see who breaks the build.

 Every commit (to baseline) should be built – Every commit made to the
application, needs to be successfully built. If the build fails for whatever reason,
then the code needs to be changed to ensure the build passes.

 Keep the build fast – If the build is slow, then it would indicate a problem in the
entire Continuous Integration process. Ensure that the builds are always limited to
a duration, preferably should never go beyond 10 minutes.

 Everyone can see the results of the latest build – The TeamCity dashboard
gives everyone a view of all the builds, which have either passed or failed. This
gives a good insight to all the people who are involved in the Continuous Integration
process.

182