This presentation would guide the user about -> why Automated Build ->How to automat Build -> and Teamcity

1. Build A Project
Build Using
Automated
Team City
-: Md. Jawed
jawed.ace@gmail.com

2. BUILD Automation
Manual What are we…
Automate
Build
Where do we want to be..
TeamCity
+
MsBuild
How do we get there..

3. Problem Statement
Currently the Code is getting Compiled on Developer Local machine involvement
of Manual Steps.
Which is prone for error(s) as:
1. Time Consuming.
2. Trigger some build operations from within a development environment (IDE) is
usually not sufficient: as it is often the case that some build operations are not
supported within the IDE, it must be possible to perform a build outside of the IDE.
3. Introduce of Human Error.
4. No centralized Drop location
5. No instant Build notification to other team members about whether build failed or
passed.
6. No Dedicated Build server.
7. Currently while compiling the code no Unit test, Code coverage and other analyses
process getting executed. Just straight forward F5 or right click Select Build of
respective project.

4. Automated Build Process
An automated build process compiles, deploys and then runs build verification tests
(BVTs) against the latest source code for a project at regular, predetermined intervals.
Then a “build report,” which details the success or failure of the build process, is
disseminated to the project stakeholders. The build report is analyzed to determine
what areas of the project need attention and/or if the project should be rolled back
to an earlier version/build.
The power of an automated build process is it can be scheduled to be run during “off
hours” so it can help ensure the stability of the project without taking cycles directly
away from the development time. This topic provides an overview of the build
process, describes how build verification testing fits into the build process, describes
aspects of functional testing used during build verification testing and provides
information about the importance of automating the build process.

5. Automated Build Process
Advantages :
1. No More F5 or Right click Build.
2. An automated build process runs faster, saving valuable time in the development and
deployment process.
3. An automated build requires less manual involvement, reducing the developer’s work load.
4. An automated build is more reliable because it reduces the number of opportunities for
human error.
5. In an automated build process all actions are scripted, which creates intrinsic
documentation of the steps involved in the build.
6. Builds Definition based on Environment like separated Build for DEV, DEV-Q, test and
Production.
7. Build notifications.
8. Integrated the Build to run Unit test, Code Coverage or code Quality while compiling the
tool. And published the result to Respective Stack Holder.
9. Builds can run at night – less network load, effective resource utilization
-Early error detection (e.g. continuous integration, automated unit testing)
-Automatic log archiving (all the information is saved)
-Better processes – automation requires process revision and simplification, which
more often than not leads to process improvement.
10. More Important
Improved Software Quality

6. Solution
We have decided to Use Team City to Automate our Build Process.
What TeamCity Offers
• Software build automation and management
• Team communication for the above
• Code inspection and coverage analysis
• Platform agnostic
• Free professional version
• Automate code analyzing, compiling, and testing processes, providing instant
• feedback on build progress, problems and test failures, all in simple, intuitive
• web-interface;
• Run multiple builds and tests under different configurations and platforms
• simultaneously.
• Perform Pre-tested commits, helping the rest of a team sustain an
• uninterrupted workflow.
• Have build history insight with customizable statistics on build duration, success
rate, code quality and custom metrics.

7. Pulling It All Together
• Periodically (to process daily or nightly builds), or
• upon version control system check-in (by setting up VCS triggers), or
• upon another build successful completion (by setting up dependencies).
• TeamCity offers multiple ways to instantly notify you about build problems or any
other changes in your projects
• Detailed Test Results Analysis
• Analysis of Unit Tests code coverage
• Build History
 For more information visit Below Link
http://www.jetbrains.com/teamcity/features/index.html

8. Approaches
Separate Build server installed with Teamcity and Different Builds definition for respective
Branch, Trunk, Tag and for Individual use.
SVN Structure Team City Builds Drop Location
Dev Build Dev
Internal Test Internal
Build Test-Q
Test Build Test
Production Production
Build

9. System Requirements
To Setup Team city to Automate Build process we need below Server/Hardware and Software
 Server: Windows 2008
 Data Base: MS Sql server 2008 R2
 Software Installed: Visual Studio 2010
IIS7.0+
Nunit
Team City
any Acetarx dependencies
FXCop
 Login: Dedicated Teamcity AD ,Having SVN permission
 EmailID: Dedicated emailid for Notification.
 Port: 8111

10. END TO END

11. Private Build-pre-tested commits

12. Private Build-pre-tested commits

13. Best Practices For Project Layout in SVN
Here are some best practices for getting the most out of your project layout:
Project root – This is the anchoring point for a project. A repository may contain one
project root, or multiple roots, but each project root contains three subdirectories: /trunk,
/branches, and /tags. The use of a project root is officially recommended by the Apache
Subversion project.
Trunk - This is where you should store current release code – only! Don’t muddy the trunk
directory with revisions or release names.
Branches – Use these to work on significant changes, variations of code etc, without
disrupting the current release code.
Bug fixing on a branch – Branches should be created to fix major bugs; this allows bug
changes to be immediately worked on without disrupting whatever work is currently
underway in the trunk/development branches.
“Toe in the water” branches – Branches can be used as a code “sandbox” where new
technology can be tested without risking the working code. If things go right, the new code
can always be merged back into the trunk.
Tags – Should be used as “code milestones” providing a snapshot of the code at specific
points in its history.
Tagging bug fix / development branches – when creating a code or bug fix branch, it’s
useful to create a “pre” tag, and a “post” tag after the bug fix or code change has been
completed:
http://10.2.5.2:9880/encom/tags/PRE_authchange_bug9343
http://10.2.5.2:9880/encom/tags/POST_authchange_bug9343

14. Perform Operation
Copy to drop
Published location
Run test
Compilation
Check
Out on
Agent

15. Questions & Answers