Build A Project Automated Build Using Team City

Build A Project Automated Build Using Team City Rajesh Kumar rajesh@scm. Galaxy. com

BUILD Automation Manual What are we… Automate Build Team. City + Ms. Build/NANT Where do we want to be. . How do we get there. .

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 F 5 or right click Select Build of respective project.

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.

Automated Build Process Advantages : 1. No More F 5 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

Solution We have decided to Use Team City to Automate our Build Process. What Team. City 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.

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). Team. City 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

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 Dev Build Drop Location Dev Internal Test Build Internal Test -Q Test Build Test Production Build Production

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

END TO END

Private Build-pre-tested commits

Private Build-pre-tested commits

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_bug 9343 http: //10. 2. 5. 2: 9880/encom/tags/POST_authchange_bug 9343

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

Questions & Answers