automated build using teamcity
DESCRIPTION
This presentation would guide the user about -> why Automated Build ->How to automat Build -> and TeamcityTRANSCRIPT
BUILD Automation
What are we…
Where do we want to be..
How do we get there..
Manual
AutomateBuild
TeamCity +MsBuild
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.
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 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
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.
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 Linkhttp://www.jetbrains.com/teamcity/features/index.html
Approaches
Separate Build server installed with Teamcity and Different Builds definition for respectiveBranch, Trunk, Tag and for Individual use.
SVN Structure Team City Builds Drop Location
Dev Build
Internal Test Build
Test Build
Production Build
Dev
Internal Test-Q
Test
Production
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+NunitTeam Cityany Acetarx dependenciesFXCop
Login: Dedicated Teamcity AD ,Having SVN permission EmailID: Dedicated emailid for Notification. Port: 8111
END TO END
Private Build-pre-tested commits
Private Build-pre-tested commits
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_bug9343http://10.2.5.2:9880/encom/tags/POST_authchange_bug9343
Best Practices For Project Layout in SVN
Perform Operation
Check Out on Agent
Compilation
Run test
Published Copy to drop location
Questions & Answers