Automated Build using teamcity

Automated Build using 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 theCode 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 Anautomated 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 AllTogether • 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 serverinstalled 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 SetupTeam 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 ForProject 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