Build A Project Build UsingAutomated Team City -: Md. Jawed firstname.lastname@example.org
BUILD AutomationManual What are we… Automate Build Where do we want to be..TeamCity +MsBuild How do we get there..
Problem StatementCurrently the Code is getting Compiled on Developer Local machine involvementof 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 location5. 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 ProcessAn 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, isdisseminated to the project stakeholders. The build report is analyzed to determinewhat areas of the project need attention and/or if the project should be rolled backto an earlier version/build.The power of an automated build process is it can be scheduled to be run during “offhours” so it can help ensure the stability of the project without taking cycles directlyaway from the development time. This topic provides an overview of the buildprocess, describes how build verification testing fits into the build process, describesaspects of functional testing used during build verification testing and providesinformation about the importance of automating the build process.
Automated Build ProcessAdvantages :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 ImportantImproved 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
ApproachesSeparate 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 Dev Internal Test Internal Build Test-Q Test Build Test Production Production Build
System RequirementsTo 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
Best Practices For Project Layout in SVNHere 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 oneproject 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 ApacheSubversion project.Trunk - This is where you should store current release code – only! Don’t muddy the trunkdirectory with revisions or release names.Branches – Use these to work on significant changes, variations of code etc, withoutdisrupting the current release code.Bug fixing on a branch – Branches should be created to fix major bugs; this allows bugchanges to be immediately worked on without disrupting whatever work is currentlyunderway in the trunk/development branches.“Toe in the water” branches – Branches can be used as a code “sandbox” where newtechnology can be tested without risking the working code. If things go right, the new codecan always be merged back into the trunk.Tags – Should be used as “code milestones” providing a snapshot of the code at specificpoints in its history.Tagging bug fix / development branches – when creating a code or bug fix branch, it’suseful to create a “pre” tag, and a “post” tag after the bug fix or code change has beencompleted:http://10.2.5.2:9880/encom/tags/PRE_authchange_bug9343http://10.2.5.2:9880/encom/tags/POST_authchange_bug9343
Perform Operation Copy to drop Published location Run test CompilationCheckOut onAgent