IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013 ISSN (Online): 2230-7893 www.IJCEM.org IJCEM www.ijcem.org 67 Visual Studio - Continuous Integration Rama Murari 1 , Veerabhadraiah Sandru 2 1,2 HiTech ISU Assurance CoE TATA CONSULTANCY SERVICES LIMITED Deccan Park, Hi-Tech City, Madhapur, Hyderabad, India. Abstract Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least once a day - leading to multiple integrations. The shift in the development models from waterfall to agile, the distributed environments, parallel development, frequent and rapid feedback, inspections, deployment and repeated automated testing encourages the organizations to adapt continuous integration. Continuous integration is a practice to be followed by the teams in addition to the usage of tools for automating the process. There are different tools for different elements of the continuous integration like build tools, test tools, code coverage tools, deployment tools etc. These tools are provided by different vendors. Organizations’ selection of CI tools becomes tedious as a careful selection of mix and match of the tools has to be done after thorough evaluation. Visual Studio provides a one stop shop for continuous integration implementation by having features to support all these needs of continuous integration. Organizations which have heavily invested in Microsoft technologies or moving towards it can look at Visual Studio for their CI needs. The tight integration of Microsoft technologies, tools and Visual Studio makes a valuable proposition for customers This paper provides the quick overview on the philosophy behind continuous integration and gives details of VS support for CI practice and deep dives into the various features of VS that will support CI implementation. Keywords: Continuous Integration, Team Foundation Server and Continuous Integration, Tools for Continuous Integration, Microsoft Continuous integration, Visual Studio support for Continuous Integration 1. Introduction In earlier days with waterfall development methodology, integration was a task that was taken up only after the individual components are developed. Integration testing would come into picture after completion of development phase. When application to be developed had many complex components and required lots of integrations, it typically resulted in “Integration hell” where the identification of the root cause of the problem was very difficult. This big bang approach of integration testing resulted in cost overruns, cycle time slips, late discovery of defects, poor code quality and delays in time to market. With the onset of Agile methodology adaption and parallel feature development, there is a need for early and frequent builds with static quality checks for every code change. This paved the way for the genesis of Continuous Integration which laid emphasis on both frequent integrations and tests. FIGURE 1 shows the gradual evolution of Continuous Integration (hereafter referred a CI) from periodic builds to builds with testing for every change. FIGURE 1: Evolution of CI Next Section covers the key concepts of Continuous Integration. 2. Continuous Integration - Overview Martin Fowler [1] who is considered the guru of Continuous integration defines CI as follows Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. CI leads to early detection of code, build, test and deployment failures thus reducing the cost to fixing the failures. Teams have to be proactive rather than reactive for practicing CI. CI addresses the risks faster and in
8
Embed
Visual Studio - Continuous Integration · IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013 ISSN (Online): 2230-7893 IJCEM 67 Visual
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013
ISSN (Online): 2230-7893
www.IJCEM.org
IJCEM
www.ijcem.org
67
Visual Studio - Continuous Integration
Rama Murari1, Veerabhadraiah Sandru
2
1,2HiTech ISU Assurance CoE
TATA CONSULTANCY SERVICES LIMITED
Deccan Park, Hi-Tech City, Madhapur, Hyderabad, India.
Abstract Continuous Integration is a software development practice
where members of a team integrate their work frequently,
usually each person integrates at least once a day - leading to
multiple integrations.
The shift in the development models from waterfall to agile, the
distributed environments, parallel development, frequent and
rapid feedback, inspections, deployment and repeated automated
testing encourages the organizations to adapt continuous
integration.
Continuous integration is a practice to be followed by the teams
in addition to the usage of tools for automating the process.
There are different tools for different elements of the continuous
integration like build tools, test tools, code coverage tools,
deployment tools etc. These tools are provided by different
vendors. Organizations’ selection of CI tools becomes tedious as
a careful selection of mix and match of the tools has to be done
after thorough evaluation.
Visual Studio provides a one stop shop for continuous
integration implementation by having features to support all
these needs of continuous integration. Organizations which
have heavily invested in Microsoft technologies or moving
towards it can look at Visual Studio for their CI needs. The tight
integration of Microsoft technologies, tools and Visual Studio
makes a valuable proposition for customers
This paper provides the quick overview on the philosophy
behind continuous integration and gives details of VS support
for CI practice and deep dives into the various features of VS
that will support CI implementation.
Keywords: Continuous Integration, Team Foundation Server
and Continuous Integration, Tools for Continuous Integration,
Microsoft Continuous integration, Visual Studio support for
Continuous Integration
1. Introduction In earlier days with waterfall development methodology,
integration was a task that was taken up only after the
individual components are developed. Integration testing would
come into picture after completion of development phase. When
application to be developed had many complex components and
required lots of integrations, it typically resulted in “Integration
hell” where the identification of the root cause of the problem
was very difficult. This big bang approach of integration testing
resulted in cost overruns, cycle time slips, late discovery of
defects, poor code quality and delays in time to market.
With the onset of Agile methodology adaption and parallel
feature development, there is a need for early and frequent
builds with static quality checks for every code change. This
paved the way for the genesis of Continuous Integration which
laid emphasis on both frequent integrations and tests. FIGURE
1 shows the gradual evolution of Continuous Integration
(hereafter referred a CI) from periodic builds to builds with
testing for every change.
FIGURE 1: Evolution of CI
Next Section covers the key concepts of Continuous Integration.
2. Continuous Integration - Overview
Martin Fowler[1] who is considered the guru of
Continuous integration defines CI as follows Continuous
Integration is a software development practice where
members of a team integrate their work frequently,
usually each person integrates at least daily - leading to
multiple integrations per day. Each integration is verified
by an automated build (including test) to detect
integration errors as quickly as possible.
CI leads to early detection of code, build, test and
deployment failures thus reducing the cost to fixing the
failures. Teams have to be proactive rather than reactive
for practicing CI. CI addresses the risks faster and in
IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013
ISSN (Online): 2230-7893
www.IJCEM.org
IJCEM
www.ijcem.org
68
smaller increments. It creates the confidence in the
application being developed as the overall health of the
progress can be measured several times a day.
The basic principles of continuous integration are as
follows
Maintain a code repository
Automate the build
Make the build self-testing
Everyone commits to the baseline every day
Every commit (to baseline) should be built
Keep the build fast
Test in a clone of the production environment
Make it easy to get the latest deliverables
Everyone can see the results of the latest build
Automate deployment
Continuous Integration can be either manual or
automated. Continuous integration is at its best with
automation of different processes in addition to the
practices. FIGURE 2 shows the continuous integration
work flow and TABLE I provide the type of tools required
for CI implementation.
FIGURE 2: Continuous Integration flow
Code changes are committee to the source control by the
development team. The CI server continuously polls the
changes and triggers the builds periodically. The
successful builds are deployed and tests are run to assess
the quality and impact of the code changes. The results of
the builds, deployment and tests are reported immediately.
This process is practiced continuously. In a nutshell, CI
gives instant feedback on the code changes, progress of
the build, deployment and tests. A typical continuous
integration server facilitates all the above activities. This
decreases the human inventions by automation and
enables continuous integrations.
In the market there are numerous enterprise-ready
continuous integration servers which provide rich features
such as source control, build management, release
management, role-based security ,notifications and
seamless integrations with 3rd party tools. Jenkins and
Cruise Control are widely used CI servers. The following
table gives a list of commercial and open source CI
servers. TABLE I
CONTINUOUS INTEGRATION SERVERS
Solution
Open
Source
Latest
Version Source Link Source
TFS N 2012 http://tfs.visualstudio.com/ Microsoft
Jenkins N 1.499 http://jenkins-ci.org/ Oracle
Cruise Control Y 2.8.4 http://cruisecontrol.sourceforge.net Sourceforge
Hudson Y 3.0.0 http://hudson-ci.org/ Eclipse
TeamCity Y 7.1.3 http://www.jetbrains.com/teamcity JetBrains
AnthillPro N 3.8 http://www.urbancode.com Urbancode
Bamboo N 4.3.3 http://www.atlassian.com Atlassian
Continuum Y 1.3.8 http://continuum.apache.org Apache
Continua CI N 7.0.0.2056 http://www.FinalBuilder.com VSoft Technologies
Pulse Y 2.5.15 http://www.zutubi.com/ Zutubi
While Jenkins remains the well known CI server,
Microsoft’s Visual Studio now has all the key features to
support the Continuous Integration without the need for
having varied tools for different CI elements. This would
be extremely useful for the customers who have embraced
Microsoft technologies in the application development
environment.
This paper gives the high level overview of the features of
CI and how VS/TFS support these features. Microsoft
msdn site has further configuration details for CI
implementation.
3. Visual Studio (VS) Support for Continuous
Integration
FIGURE 3 shows how Visual Studio along with Team
Foundation Server supports the CI process. VS supports
implementation of CI by offering rich features such as
version control, build management (Team foundation
Build/TFB), Unit Testing (Visual Studio) and static
testing like code coverage, code analysis. In addition to
code maintenance and build, TFS/Visual Studio also has
extensive features for deployment and installation. TFS
supports notifications and alerts. TFS and Visual Studio
are interdependent and features that can be triggered from
Visual Studio are given here though they may in turn
interact with TFS.
IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013
ISSN (Online): 2230-7893
www.IJCEM.org
IJCEM
www.ijcem.org
69
FIGURE 3: CI supporting TFS/VS features
Details of key features of TFS in lieu of the above are
given in the next section
4. Details Of VS Key Continuous
Integration Features
Visual Studio provides a single point solution for all CI
supporting features like source control, build
management, test management, work item tracking and
lab management. The TFS source control feature helps in
code maintenance so that the team has the same version at
any given point of time. The code committed to the
version control automatically triggers the inspections,
builds and unit tests. The TFS build management system
(Build controllers/agents) supports compiling and
building the code as per the build definition. The lab
management in TFS allows creation of virtual
environments with required configuration. The Test
Controller along with the Test agents run the test cases in
the test environments. FIGURE 4 provides the high level
architecture of TFS that supports above mentioned
features.
FIGURE I TFS Architecture
TABLE II shows a snapshot of the features available in
VS and TFS to support Continuous Integration process. TABLE II
VISUAL STUDIO: KEY CONTINUOUS INTEGRATION
FEATURES
4.1 Source Control Support in TFS
TFS serves as central repository for source code and the
other project artifacts. It stores all the project artifacts
and all the changes made to them over time. It provides
controlled access to the all the project artifacts. It provides
the flexibility and ease to maintain different versions of
the application. The code can be merged or restored back
to any stage at any point of time. It also supports
versioning of database schema to keep data and code in
synch.
The most commonly used SCM (Software Configuration
Management) tools used are ClearCase, CVS, Git,
Mercurial, Perforce, StarTeam, Subversion, MKS,
SourceGear Vault, and Visual SourceSafe.
TFS provides the main baseline structure. As per the
project needs, branches are created for maintenance of the
code.TFS allows the following branching strategies
Feature Branching: Branching based on the features
to be developed Release Branching: A branch is created to stabilize
the release and later merged to main branch after the
release.
Quality Branching: Branching done for different
teams with focus on quality
TFS allows merging of code from different branches.
The code is checked out, appropriate changes are made
and changes are checked in after conflict resolution. In
parallel development, multiple developers can work
simultaneous on the same code base. Developers create a
IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013
ISSN (Online): 2230-7893
www.IJCEM.org
IJCEM
www.ijcem.org
70
local workspace on their local machines. The workspace
is mapped to the TFS server code base. TFS proxy server
provides local cache for the version controlled
information that will synchronize with the master copy in
the central TFS server regularly.
Developers make changes to the code in the local
workspace. Parallel development might result in
conflicting changes. Visual Studio along with TFS aids in
comparing the differences and resolving the conflicts
either manually or automatically. The changes in the
workspace can be shelved. The pending changes in the
shelve-sets can be discarded.
When the check-in is triggered, the check-in policies are
validated. TFS supports the policy validations for work
items, builds, tests, code coverage analysis etc.
Additionally if the available policies do not match to the
needs of the project, it allows creation of custom policies.
After automated tests and code coverage is run, changes
are checked into TFS with appropriate comments.
TABLE III gives the common source control features and
TFS support for these features TABLE III
TFS/VS SOURCE CONTROL FEATURES
The check-ins triggers the builds as per the build
configuration. The next section gives details of the build
architecture and the build process.
4.2 Build Support
TFS supports build using Team Foundation Build. Team
Foundation Build uses MSBuild script to control the build
process. The code, database schemas and the other project
artifacts from the source control are used to build the
application executables.
As part of build definition TFS allows specifying the
program and testing elements for execution, the triggers
points of build, deployment and the status retention of
different builds that helps the developers, testers,
build/release managers and project managers.
Visual Studio supports the following build triggers.
Manual : Builds that are triggered manually
Rolling Check-in Builds: Build triggered after regular
intervals of time. Check-ins are accumulated till
previous build succeeds
Continuous Integration Builds: Build triggered after
every check-in, code is checked-in even if the tests
fail.
Gated Check-in builds: Check-in is done only after
the changes merge and build is successful.
Scheduled Builds: Builds is trigger on any day and
any time.
Visual Studio supports Continuous Integration by
triggering Continuous Integration builds or Gated
Checkin builds. For Continuous Integration build
configuration if build fails the executable is not available
till the build is fixed. This interrupts the work of the team,
hence Gated checkin configuration helps to overcome this
hurdle by not committing the code to TFS if it breaks the
build. This helps the teams to work, uninterrupted by
failures.
TFS allows the build steps to be specified as workflow
that uses Windows Workflow. TFS provides three
predefined build definition process templates (default,
upgrade and labDefault). The build steps are complex
hence Visual Studio has a visual representation to easily
understand and modify the workflow as per the project
needs.
After the build is completed, executables are deployed in
the different environments. TFS also provides the
reporting capabilities giving all the build details. Emails
and alerts can be triggered for the status reports.
Build reports gives the results of build completion, code
analysis and the tests run. For build failures link are
provided to the bug work item, based on which the teams
are notified and the failure is fixed without delay. Build
Report also provides the direct navigation to the
changesets, code analysis warning and the test results.
The data from the build report is used for metrics
reporting.
A daily build shows all code changes and work items
incorporated since the last daily build, whereas a release
IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013
ISSN (Online): 2230-7893
www.IJCEM.org
IJCEM
www.ijcem.org
71
build shows a list of all changes checked in since the last
release.
The following table gives the few key build features of any
Build management application and the how these features
are supported in Visual Studio/TFS. TABLE IV
TFS BUILD FEATURES
Lab Management feature supports in setting up the test
labs on physical or virtual machines. Templates can be
created for environment and can be used for recreation.
Visual Studio helps to run tests remotely, distribute tests
across multiple machines, by configuring test controller,
test agents, and test settings file. The build definition
supports automatic deployment and test runs.
4.3 Code Coverage
Visual Studio facilitates code coverage which measures
the percentage of code which is covered by automated
tests. Code coverage measurement determines which
statements in a body of code have been executed through a
test run, and which statements have not. Visual Studio
supports code coverage analysis. This is a structural
testing technique which compares the test program
behavior against the source code
Code coverage analysis helps in finding the testing
deficiencies in covering the areas of the program. Test
cases can be added for better coverage while redundant
test cases can be removed to improve the quality.
TABLE V
VISUAL STUDIO CODE COVERAGE
4.4 Code Analysis
Visual Studio supports code analysis for both managed
and unmanaged code. A set of predefined rulesets are
defined and categorized. New customized rule-sets can
also be created.
The rulesets check the rules of some of the features like
Security, Design, Globalization etc. The rules cover wide
range of warnings from key aspects such as performance,
interoperability, reliability etc. The Code Analysis tool
provides warnings/errors that indicate rule violations in
libraries or executables.
The following gives the list of rulesets and rules
categories. TABLE VI
VISUAL STUDIO CODE ANALYSIS
4.5 Unit Testing
Visual Studio provides Unit Testing framework for testing
the code and databases. The generation of unit tests for
the methods is made simple. Visual Studio creates the
sample test method for the code with the default inputs,
outputs and validation statements. Default assertions
statements are created which need to be refined with valid
IJCEM International Journal of Computational Engineering & Management, Vol. 16 Issue 6, November 2013
ISSN (Online): 2230-7893
www.IJCEM.org
IJCEM
www.ijcem.org
72
inputs, outputs and validation. Additional logic and
assertions can also be incorporated. Selected tests can be
executed. The test results can be saved to disk, published
in TFS or exported as required. Predefined assertions are
available and can be extended. The exceptions validation
can also be handled in unit tests
Database Unit Testing helps with default schema, schema