I want to use the Amazon EC2 integration in TeamCity to launch build agents ‘in the cloud’. The problem I am having is that when the agent starts, it sees the server and registers, then just sits there waiting. On the server side, the agent appears as ‘disconnected’.

Examining the settings, the agent’s IP address appears to be that of the external NIC. What I think might be happening is that the traffic is undergoing Network Address Translation (NAT) so that TeamCity always thinks the agent is locally installed and therefore can’t communicate with the actual remote agent. This seems to happen even though I have a permanent static IP address dedicated to TeamCity.

So, the question is this. How can I make traffic to a specific IP address pass through the ISA server un-NATted?
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post TeamCity EC2 Integration via ISA Server appeared first on scmGalaxy.

The post Finding out who broke the most builds in Teamcity appeared first on scmGalaxy.

Hi,

We have been using CC.NET as our CI server for a month or so now, which has worked ok with TFS. In the config we were able to specify the TFS server, username, password, project and workspace which is all good.

Now we are moving over to TeamCity mainly because it just seams more solid and is much nicer to use. The problem is getting it work with TFS.

For the purpose of this, both the workspace and machine name are “BuildMachine”, username is “BuildUser” TFS project is “$/Project/Dev/Website”

I seam to have set it up correctly, I think, as when testing the connection it is successful. When I run a build I get a TFS error: “RunBuildException when running build stage UpdateSourcesFromServer.”

It goes on to say: “No matched workspaces were found. Will recreate workspace and perofming clean checkout.”

It then tries to create a new workspace something like this: TeamCity-S-sqa9qe2aulx22gz4rzkogl5kr/BuildUser

It tries to set up some mappings and then fails because: “The working folder C:\ is already in use by the workspace BuildMachine;BuildUser on computer BuildMachine”.

This seams ok as this is the workspace that CC.net was using, and c:\project\dev\website is the path to the project. The problem is, why didn’t TeamCity pick this up and use this workspace? Why does it try to create its own new one? Any idea how I can fix this?

Thanks
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post TeamCity with TFS – workspace problems appeared first on scmGalaxy.

Test connection failed in Airvata :: compile
List remote refs failed: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I am wondering as yesterday it was working without any issues but now its not working any more…..

-Rajesh
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: Github VCS connection – List remote refs failed: javax.net.ssl.SSLHand
Updated…..
I was using https mode of gihub url which is not working and throwing same error as below but when i moved to ssh

eg. git@github.com:scmgalaxy/airavata.git
along with
user name – git
Uploaded key options from team city in which pvt key has been added. it works!!!

I will troubleshoot later point of time, why https is not working suddenly.
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Github VCS connection – List remote refs failed: javax.net.ssl.SSLHand appeared first on scmGalaxy.

• Earlier finding & addressing of Bugs – By implementing continuous integration you can do frequent testings which helps to find bugs and error quickly before they ruin your whole efforts later.

• Improve software quality – Early finding issues in the codes, developers can act on them early before they grow into larger problems later,  which ultimately improves the quality of the software.

• Reduce the time it takes to validate – CI immensely reduce the waiting time to find out if your code’s going to work or not.

• Release new software updates – Doing frequently and numbers of time automated build and test of codes helps teams to deliver the new updates to the user more often and faster.

• Open Source
• Easy installation
• Easy configuration
• Rich plugin ecosystem
• Extensibility
• Distributed builds
• Platform: Cross-platform

• Free and Paid
• Gated Commits (prevents developers from breaking sources in a version control system by running the build remotely for local changes prior to commit)
• Build Grid. Allows running multiple builds and tests under different platforms and environments simultaneously
• Integrated code coverage, inspections and duplicates search
• Integration with IDEs: Eclipse, IntelliJ IDEA, Visual Studio
• Platforms supported: Java, .NET and Ruby
• Supports cloud integration

• Open source
• Supports pull request and branch build flow
• Parallel test runs
• Easily synchronize with GitHub
• Flexible plans for every size project
• Platforms: Hosted
• Supports Many Languages like Node js, php, Xcode, python and many more.

• Trial-ware
• Supports many languages like Python, C#, HTML, Java and various others
• Work in any environment like Visual Studio, Xcode, Eclipse, or any Git client
• Extensible tool can work effectively for all shapes and sizes

• Paid and Free trial
• Cross platform
• Allow to Import data from Jenkins
• Works with JIRA and Bitbucket
• Works with others tools like CodeDeply, Ducker, Maven, Git, SVN, Mercurial, Ant, AWS, Amazon S3 buckets
• Support many languages
• Can run multiple builds parerally
• customization of triggers and variables
• Very fast and easy to use

• Licensing plans
• Hosted service
• Server virtualization
• Integrated with middle-ware
• Clear visibility: what is deployed where and who changed what
• Configuration and security differences across environments
• Orchestration of changes across servers, tiers and components
• Automated provisioning, updating, and de-provisioning of cloud environments
• Automated, consistent deployments and rollbacks of applications

• Availability: Free with paid support
• Platform: Windows, Linux, Mac
• Pipeline Concept
• Parallel execution of the tasks
• Support Many languages
• Easily compare builds
• Clearly visualize workflow
• Promote trusted artifacts
• Plugins availability

• Platform: Hosted
• Availability: Free and paid with trial
• Easy to learn
• GitLab CI is fully integrated with GitLab
• Docker support
• Pipeline Concept
• Supports multi-languages – Java, PHP, Ruby, C etc..
• Parallel builds
• Autoscaling
• Build artifacts

• Availability: Free and paid with trial
• Platform: Cross platform
• Supported languages includes Java, Ruby/Rails, Python, Node.js, PHP, Haskell, and Skala
• Supports Docker
• Flexible pricing model

• Availability: Free and paid
• Platform: Hosted
• ParallelCI feature
• Supported languages Go Ruby on Rails, Node.js, PHP, Java, Go, Dart etc..
• Flexible Pricing
• Docker Supported (by upgrading)
• Easy to setup, fast and reliable

The post Top 10 Continuous Integration Tools | List of Best CI Tools | scmGalaxy appeared first on scmGalaxy.

This course will also help professionals who is somehow associated with cloud infrasture, managing the team or from development and Testing background.

1. Project Managers,
2. Testing Professionals,
3. Software Developers and Architects,

And have experience with either administering IT infrastructure/applications or with automation

Pre-requisites

1. Basic understanding of linux/unix system concepts
2. Familiarity with Command Line Interface (CLI)
3. Familiarity with a Text Editor
4. Experience with managing systems/applications/infrastructure or with deployments/automation

How to contact?

1. email to info@scmGalaxy.com
2. Phone to +91 9939272785 (India)
3. Phone to +91 7739774984 (India)
4. WhatsApp  – +91 9939272785 
5. Skype – RajeshKumarIN

How to enroll for this training?

Testimonials : What professionals feel about our training?

Please click on this url to know what our student think about training program- Click Here

FAQ : Do you have additional questions?

Please click on this url to know Click Here

Why Online training is more preferred than classroom?

Please click on this url to know Click Here

Classroom Training and Workshop?

We do offer classroom training and workshop in Bangalore, Hyderabad, Pune, Mumbai and New Delhi. For more details, please send us an email to info@scmGalaxy.com

Also, you can follow this url Click Here

Fees Details (Fixed)

With Lifetime Enrollment
DevOps + Build & Release – INR 30K

Without Lifetime Enrollment
DevOps + Build & Release – INR 25K

Training Time and Calender

Please click on this url to know Click Here

Time

1. 7:00 AM IST to 8:30 AM IST
2. 8:00 PM IST to 9:30 PM IST

Why to Learn Build and Release

1. Technical benefits: Continuous software delivery
2. Technical benefits: Less complex problems to fix
3. Technical benefits: Faster resolution of problems
4. Business benefits: Faster delivery of features
5. Business benefits: More stable operating environments
6. Business benefits: More time available to add value (rather than fix/maintain)

Course Features: Build and Release

1. 30 Hours instructor led online class
2. Hands on Approach – We emphasize on learning by doing.
3. Life time free re-enrollment to future DevOps courses
4. Life time free access to all learning materials including
   1. Class recordings
   2. Presentations
   3. Sample Code
   4. Projects
5. Total Lab Infrasture in cloud and 24×7 available
6. 70% of the class is consist of Lab
7. Each week assignments (total 4) with personal assistance
8. Two real time senario based projects with standard evaluation
9. 24×7 online support to queries during and after the course completion
10. 1 dedicated class for Interview preparations
11. Online Quizs for each tool
12. Lifetime Free access to Our Learning Portal for FreeVideos, Scripts Collection, Quiz, Interview Guide, Projects, Tutorials etc.
13. Two Courses One Fee – DevOps and Build & Release which includes Chef and Puppet courses are together is being offered to our students.
14. Life time Enrollment – Once you enroll, its life time enrollment. That means you can attend any number of session, Any Batch, Any time without paying another time for DevOps, Build & Release, Chef and Puppet. That means all courses, only one fees for life time.

Agenda of the training: Tools and Technologies

Concept and Process

1. Software Configuration Management overview
2. Elements of Software Configuration Management
3. Introduction of Version management / Source Code Management
4. Overview of Build management
5. Overview of Packaging management
6. Build and Release Concept and Process
7. Overview of Release and Deployment management
8. DevOps Concept and Process
9. Continuous Integration and Delivery Process

Operating Systems

1. Windows Administrator fundamental

Source Code Management

1. Git Fundamental
2. Git Advance
3. Team Foundation Source Code

Build Tools

1. MsBuild Fundamental
2. NANT 
3. Team Foundation Build

Scripting

1. Powershell Scripting – Fundamental

Package Management in Linux and Windows

1. Nuget

Artifact Repository Tools

1. Nuget

Configuration Management Tools

1. Puppet Fundamental
2. Puppet Advance
3. Octopus

Incident Management tools

1. Jira Fundamental

Continuous Integration Tools

1. Jenkins Fundamental
2. Jenkins Advance
3. Teamcity Fundamental

CI/CD Concept and Implementation

1. Concept of Continuous Integration
2. Concept of Continuous Deployment
3. Concept of Continuous Delivery
4. CI/CD Implementation

The post DOT NET Build and Release Training | Build and Release DOTNET Course appeared first on scmGalaxy.

We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters.

Meta-Runners provide a straightforward way to create custom build runners. Meta-Runners can be thought of as a way to avoid duplications in build steps across build configurations.

In Chapter 3, Getting Your CI Up and Running, we created the deploy-to-test build configuration that deploys the Django application to Heroku. Using this build configuration as an example, we can see how we can extract a Meta-Runner Deploy To Heroku that can be used by any build configuration that wants to deploy to Heroku.

Recall that the deploy-to-test build configuration had a simple command-line runner that executed the following commands:

git remote add heroku git@heroku.com:django-ci-example.git  git push heroku master

To create a generic Meta-Runner out of this, we need to provide a way to push to any remote, rather than just git@heroku.com:django-ci-example.git.

As expected, we will do this by extracting the remote out into a build parameter. The command-line runner will have the following as the Custom Script to be run:

git remote add heroku %heroku.remote%  git push heroku master

We will provide the value for the %heroku.remote% parameter in the Build Parameters section of the build configuration.

Now we are ready to create a Meta-Runner from this build configuration. This can be done by clicking on the Extract Meta-Runner button in the right-hand side bar of the build configuration settings page. This brings up the Extract Meta-Runner dialog, which is shown in the following screenshot:

In the dialog, we give a name to the Meta-Runner. This is the name that will appear in the Runner Type field when configuring a build step for a build configuration.

Click on Extract to create the Meta-Runner. Once the Meta-Runner is created, we can see it listed in the Meta-Runners tab on the project administration page. We can also edit the Meta-Runner to fine-tune it as desired.

The following screenshot shows the edit page of the Deploy To Heroku Meta-Runner that we just created:

The Meta-Runner extracts all the parameters and steps defined in the build configuration. We can edit the Meta-Runner to have only the necessary parameters and steps.

Using Meta-Runners

We can now use the Meta-Runner that we created pretty much like a normal build runner. We will remove the existing build step in the deploy-to-test build configuration (from which we extracted the Meta-Runner) and add a Deploy To Heroku Meta-Runner-based build step.

Tip

We can also disable build steps if we don’t want to remove them while experimenting.

In the New Build Step page, for the Runner type field, the newly created Deploy To Heroku Meta-Runner is available, as shown in the following screenshot:

Once we choose the Deploy To Heroku Meta-Runner, we can see that the heroku.remote parameter is one of the fields to be configured. Since we created the Meta-Runner with the heroku.remote parameter with the value git@heroku.com:django-ci-example.git, that remote is available by default. The Deploy To Heroku runner configuration page is shown in the following screenshot:

Tip

It is possible to remove the value for parameters in the Meta-Runner XML so that no default values are present for the fields.

We can click on Save to add the build step. The new build step, based on the Deploy To Heroku Meta-Runner, will function in the same way as the previous build step based on the command-line runner.

Note

Of course, the value of Meta-Runners becomes more apparent when we create them out of multiple build steps. The same set of steps that may be repeated across multiple configurations can be extracted into Meta-Runners.

Reference Book – Learning Continuous Integration with TeamCity by Learning Continuous Integration with TeamCity

The post Build Configuration Templates in Teamcity | Teamcity Guide appeared first on scmGalaxy.

We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters.

Meta-Runners provide a straightforward way to create custom build runners. Meta-Runners can be thought of as a way to avoid duplications in build steps across build configurations.

In Chapter 3, Getting Your CI Up and Running, we created the deploy-to-test build configuration that deploys the Django application to Heroku. Using this build configuration as an example, we can see how we can extract a Meta-Runner Deploy To Heroku that can be used by any build configuration that wants to deploy to Heroku.

Recall that the deploy-to-test build configuration had a simple command-line runner that executed the following commands:

git remote add heroku git@heroku.com:django-ci-example.git  git push heroku master

To create a generic Meta-Runner out of this, we need to provide a way to push to any remote, rather than just git@heroku.com:django-ci-example.git.

As expected, we will do this by extracting the remote out into a build parameter. The command-line runner will have the following as the Custom Script to be run:

git remote add heroku %heroku.remote%  git push heroku master

We will provide the value for the %heroku.remote% parameter in the Build Parameters section of the build configuration.

Now we are ready to create a Meta-Runner from this build configuration. This can be done by clicking on the Extract Meta-Runner button in the right-hand side bar of the build configuration settings page. This brings up the Extract Meta-Runner dialog, which is shown in the following screenshot:

In the dialog, we give a name to the Meta-Runner. This is the name that will appear in the Runner Type field when configuring a build step for a build configuration.

Click on Extract to create the Meta-Runner. Once the Meta-Runner is created, we can see it listed in the Meta-Runners tab on the project administration page. We can also edit the Meta-Runner to fine-tune it as desired.

The following screenshot shows the edit page of the Deploy To Heroku Meta-Runner that we just created:

The Meta-Runner extracts all the parameters and steps defined in the build configuration. We can edit the Meta-Runner to have only the necessary parameters and steps.

Using Meta-Runners

We can now use the Meta-Runner that we created pretty much like a normal build runner. We will remove the existing build step in the deploy-to-test build configuration (from which we extracted the Meta-Runner) and add a Deploy To Heroku Meta-Runner-based build step.

Tip

We can also disable build steps if we don’t want to remove them while experimenting.

In the New Build Step page, for the Runner type field, the newly created Deploy To Heroku Meta-Runner is available, as shown in the following screenshot:

Once we choose the Deploy To Heroku Meta-Runner, we can see that the heroku.remote parameter is one of the fields to be configured. Since we created the Meta-Runner with the heroku.remote parameter with the value git@heroku.com:django-ci-example.git, that remote is available by default. The Deploy To Heroku runner configuration page is shown in the following screenshot:

Tip

It is possible to remove the value for parameters in the Meta-Runner XML so that no default values are present for the fields.

We can click on Save to add the build step. The new build step, based on the Deploy To Heroku Meta-Runner, will function in the same way as the previous build step based on the command-line runner.

Note

Of course, the value of Meta-Runners becomes more apparent when we create them out of multiple build steps. The same set of steps that may be repeated across multiple configurations can be extracted i

The post Going meta with Meta-Runners in TeamCity appeared first on scmGalaxy.

Click Here

scmGalaxy is a community initiatives based on Software configuration management that helps community members to optimize their software development process, Software Development Life Cycle optimization, Agile Methodologies and improve productivity across all aspects of Java development, including Build Scripts, Testing, Issue Tracking, Continuous Integration, Code Quality and more. scmGalaxy group that helps organisations optimize their software development process. We provide consulting, training and mentoring services in Agile Development Practices such as Version Management, Continuous Integration, Build Management, Test-Driven Development, Acceptance-Test Driven Development, Build Automation, Code Quality Practices and Automated Testing.

We provide job oriented training in the area of Configuration management, Build and Release Engineering. Candidates with engineering or software background and looking to either start or change their career to Build and Release Engineering, would benefit most from this training. Instructor-led training course offered in India, Bangalore, Delhi, Pune, Mumbai and Hydrabad. Instructor is an expert in Software configuration management, Build and release engineering with more than 15 years industry experience in india.The Goal of the course make the training attendants equip with all the concepts of build and release engineering.

Contact us at info@scmGalaxy.com | Call – +91 700 483 5930 | Skype – scmGalaxy

Course Objectives
To bring your team up to speed with agile development, We can also run the from Continuous Integration to Continuous Delivery with autoamted course within your premises.

Course Schedule
This course is an intensive 1-day & 2-day workshop with a mixture of teaching and lab exercises. Currently, this course is offered exclusively as an on-site course. Please contact us for more details.

Audience
This is a hands-on, practical course designed to teach specialised skills for real-world development situations. It is thus primarily aimed at a SCM Engineer, Build/Release Engineer and developer audience.

Approach
The course is modular and flexible – depending on specific student needs and requests. Through our trainings, you benefit from the wide experience and architectural expertise of our team. We bring that experience to you in an highly interactive, intensely hands-on setting.

Assumptions
We assume participants have a reasonable understanding of Development in any language as well as a basic understanding of the Software Development Life Cycle.

Lab Work
All our courses are above all practical in nature. We believe that the best way to learn is by doing. So the course contains approximately 80% lab work.

Learning Resources
Each registrant will receive a copy of the student notes and lab solutions, a certificate of completion, and a CD containing all the tools covered in the course and CD containing all the tools covered in the course.

Contact Us
This course is provided on-site, and can be tailored to your particular requirements. If you would like our trainings delivered at your premises, or for any additional information please contact us. Please email us at info@scmGalaxy.com

Course outline

The basic course program is outlined here:

1. Introduction

1. Introduction to Continuous Integration
   1. Practices
   2. Benefits
   3. Continuous deployment and Continuous Delivery
   4. The build pipeline
2. Introduction to TeamCity
   1. Licensing
   2. Features
      1. First-class support for various technologies
      2. Lots of plugins
      3. REST API
      4. Comprehensive VCS support
      5. A nice dashboard UI and build history
      6. Ease of setup and comprehensive documentation
      7. Build pipeline/chains
      8. Agents and build grids
      9. IDE integrations
3. TeamCity and its competitors
   1. Jenkins
   2. ThoughtWorks’ Go
4. Summary

2. Installation

1. Installing on Windows
   1. Installing the server and the default agent
   2. Installing additional agents
2. Installation on Mac OS X
   1. Running the TeamCity server and the default agent
   2. Setting up the TeamCity server as a daemon
   3. Installing additional agents
3. Installation on Linux
   1. Running the server and the default agent
   2. Running the TeamCity server as a daemon
   3. Installing additional agents
4. Summary

3. Getting Your CI Up and Running

1. Introducing version control systems
   1. Centralized versus distributed VCSs
   2. VCSs and CI
   3. VCS used in this book
2. Setting up CI
   1. The sample project
   2. Creating a project in TeamCity
      1. Subprojects
   3. Adding build configurations
      1. VCS roots and VCS settings
      2. Introducing the build steps
      3. Running our first build
      4. Build failure conditions
      5. Triggering the build on VCS changes
   4. Build chains
      1. Deploying to Heroku
      2. Adding functional tests
         1. Parameters and build parameters
      3. Setting up the build chain
         1. Snapshot dependencies
         2. The Finish build trigger
         3. The Build chain view
   5. Fine-tuning our setup
      1. Adding coverage and unit test reports
         1. Publishing reports as artifacts
         2. XML report processing
         3. Report tabs
         4. Build and project statistics
         5. Shared resources
         6. Agent Requirements
3. Summary

4. TeamCity for Java Projects

1. Using Ant with TeamCity
   1. Installing Ant
   2. Building with Ant build files
      1. Building with Ant in a build configuration
   3. Adding some unit tests
   4. Setting up code coverage
   5. Build scripts versus TeamCity features
   6. System properties and Ant
2. Using Maven with TeamCity
   1. Installing Maven
   2. Creating a Maven project
   3. Introducing the Project Object Model (POM)
   4. Building the project
   5. Using Maven in a build configuration
   6. Setting version number
   7. Setting up code coverage for our build
   8. Maven on TeamCity, beyond the build runner
      1. Creating a Maven build configuration
      2. Global Maven settings file
      3. Setting up Maven-based triggers
3. Using Gradle with TeamCity
   1. Installing Gradle
   2. Building with Gradle on TeamCity
4. Introducing database migration tools
5. Summary

5. TeamCity for .NET Projects

1. Getting started with NAnt on TeamCity
   1. Installing NAnt
   2. Building NAnt with NAnt
   3. Building on TeamCity
      1. Adding NUnit report processing
      2. Configuring agent requirements
2. Building with MSBuild
   1. Installing MSBuild
   2. Starting an MSBuild project
   3. Building with MSBuild on TeamCity
   4. Adding an NUnit build runner
   5. Running NUnit tests using NUnit task
   6. Running NUnit tests using the task provided by TeamCity
   7. Configuring code coverage with MSBuild
3. NuGet and TeamCity
   1. Installing the NuGet command-line client
   2. Installing NuGet.exe on TeamCity agents
   3. TeamCity as a NuGet server
   4. NuGet-based build runners
   5. NuGet dependency trigger
4. Introducing PowerShell
   1. PowerShell-based build tools
   2. PowerShell build runner in TeamCity
5. Database migrations with .NET
6. Summary

6. TeamCity for Ruby Projects

1. Getting started with Rails
   1. Managing Ruby versions
   2. Introducing Bundler
      1. Installing Rails using Bundler
   3. Introducing Rake
   4. Setting up the build on TeamCity
      1. Setting up Ruby interpreter
      2. Running Capybara- and Selenium-based feature tests
2. Summary

7. TeamCity for Mobile and Other Technologies

1. CI for Android projects
   1. Generating the APK
   2. Running Calabash tests
2. Building iOS projects on TeamCity
3. Installing TeamCity plugins
   1. Installing the Python runner plugin
   2. Building with the Python build runner
   3. Introduction to TeamCity.Node plugin
4. Summary

8. Integration with Other Tools

1. IDE integrations
   1. IntelliJ platform IDEs integration
      1. Installing the plugin
      2. Configuring notifications
      3. Managing projects from the IDE
      4. Opening files and patches in IDE
      5. Remote Run
   2. Visual Studio integrations
2. GitHub integrations
   1. GitHub webhooks and services
   2. Using the TeamCity.GitHub plugin
   3. Support for pull requests
   4. Integrating with GitHub issue tracker
3. Build monitors
   1. Team Piazza
   2. Project Monitor
   3. Build lights
4. Notifications
5. Summary

9. TeamCity for a Member of the Team

1. Managing projects of interest
   1. Hiding projects
   2. Hiding build configurations
2. Navigating across projects
3. Investigating investigations
   1. Assigning investigations
   2. Viewing active investigations
   3. Managing current and muted problems
4. TeamCity universal search
5. Actions on build configurations
   1. Pausing triggers in a build configuration
   2. Checking for pending changes
   3. Enforcing clean checkout
6. Summary

10. Taking It a Level Up

1. Build configuration templates
   1. Creating templates from scratch
   2. Creating build configurations from the template
   3. Creating templates from existing build configurations
2. Going meta with Meta-Runners
   1. Using Meta-Runners
3. Build result actions
   1. Commenting on build results
   2. Tagging build results
   3. Pinning build results
   4. Promoting builds
   5. Marking the build as successful or failed
   6. Removing builds
4. Build history cleanup
   1. Cleanup rules
   2. Archiving projects
5. Configuring build priorities
6. Interacting with TeamCity from build scripts
   1. Service messages
   2. Creating teamcity-info.xml
7. Summary

11. Beyond CI – Continuous Delivery

1. What is Continuous Delivery?
2. Why Continuous Delivery?
3. The deployment pipeline
4. Implementing the deployment pipeline in TeamCity
   1. Publishing and consuming artifacts
   2. Build chain for CI
   3. Deploying to environments
   4. Environments as gates
   5. Identifying the build that is deployed in an environment
   6. Deploying any version to an environment
   7. Limiting deployment permissions to certain users
   8. Passing sensitive information during deployment
   9. Feature branching and feature toggling
5. Summary

12. Making It Production Ready

1. Using TeamCity with an external database
   1. Configuring PostgreSQL as an external database
   2. Migrating from one database to another
2. Backup and restore
   1. Taking backups from the server UI
   2. Backing up and restoring data using the maintainDB tool
   3. A manual backup
3. Handling upgrades
   1. Updating a server installed via an archive
   2. Updating TeamCity using the Windows installer
   3. Updating the agents
4. Monitoring resource usage, performance, and logs
   1. Disk space usage
   2. TeamCity server diagnostics
5. Tweaking the TeamCity JVM
6. Summary

TeamCity Training In Bangalore | TeamCity Training in India | TeamCity Training in Hydrabad | TeamCity Training in Delhi | TeamCity Training in Pune | TeamCity Trainer In Bangalore | TeamCity Trainer in India | TeamCity Trainer in Hydrabad | TeamCity Trainer in Delhi | TeamCity Trainer in Pune

The post TeamCity Training | TeamCity Course | Online | Classroom | India appeared first on scmGalaxy.

Difference between Bamboo Vs TeamCity Vs CruiseControl
TEAMCITY

• TC pre-tested commit is good.
• TC integrates to Visual Studio which is our main IDE.
• JetBrains are more focused on supporting .NET builds than Atlassian is, since JetBrains actually has .NET products so they use it internally.
• Support for .Net projects, as well as Java, in the same product (nice if you need it).
• Server-side code coverage analysis (you could get the same results by running EMMA from the Ant build.xml)
• Server-side static code analysis using IDEA inspections (nice but relies on using IDEA for development – Checkstyle and FindBugs could do something similar from Ant).
• Pre-tested commits. Sends your changes to the CI server for building before committing to version control. Your changes are only checked-in if the build succeeds and all tests pass.

BAMBOO

• Bamboo JIRA integration is awesome. I wish TeamCity provides that kind of integration.
• Bamboo on the other hand looks like a great tool too. It has so many plugins (just like JIRA). It looks nice as well. I can live without VSTD integration, but I really wanted pre-tested commit. Just a note: I did create a feature request ticket to Atlassian telling them about TC’s pre-tested commit feature.

CruiseControl

• “CruiseControl is a framework for a continuous build process.”
• “Bamboo is a continuous integration build server that offers heaps of insight on build processes and patterns via solid reporting metrics.”
• “TeamCity is an innovative, IDE independent, integrated team environment targeted for .NET and Java software developers and their managers.”
• “AnthillPro3 is a third generation Build Management Server.”

Links and Reference:
http://blog.chris-read.net/2007/02/21/quick-comparison-of-teamcity-12-bamboo-10-and-cruisecontrol-26/
http://blog.uncommons.org/2006/12/08/teamcity/
http://poorinnerlife.blogspot.com/2007/09/bamboo-disappointment.html

The post Bamboo Vs TeamCity Vs CruiseControl – Continuous Integration Expert Review appeared first on scmGalaxy.