Tag: Teamcity

TeamCity EC2 Integration via ISA Server

by scmgalaxy KTeamcityLeave a Comment on TeamCity EC2 Integration via ISA Server

rajeshkumar created the topic: TeamCity EC2 Integration via ISA Server
I have a TeamCity server which is actually installed on SBS 2003 Premium with ISA Server (firewall/proxy) installed. My ADSL connection has multiple IP addresses, which all resolve directly to my SBS external NIC. The NIC is therefore multi-homed and I have allocated one of the IP addresses specifically to TeamCity. In ISA, I’ve created an access rule to allow the traffic in. I can access my TeamCity server externally and view the web interface, that all works fine.

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

Tagged :

Finding out who broke the most builds in Teamcity

by scmgalaxy KTeamcityLeave a Comment on Finding out who broke the most builds in Teamcity

scmuser created the topic: Finding out who broke the most builds in Teamcity
Is there a simple way of finding out how many successful/broken builds a user has generated in Teamcity? We need this to find out who buys beers on friday 🙂

Tagged :

TeamCity with TFS – workspace problems

by scmgalaxy KTeamcityLeave a Comment on TeamCity with TFS – workspace problems

rajeshkumar created the topic: TeamCity with TFS – workspace problems
0 vote down star

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

Tagged :

Github VCS connection – List remote refs failed: javax.net.ssl.SSLHand

by scmgalaxy KUncategorizedLeave a Comment on Github VCS connection – List remote refs failed: javax.net.ssl.SSLHand

rajeshkumar created the topic: Github VCS connection – List remote refs failed: javax.net.ssl.SSLHand
I am facing same issues while connecting with github…

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

Tagged : /

Top 10 Continuous Integration Tools | List of Best CI Tools | scmGalaxy

by scmgalaxy KContinuous IntegrationLeave a Comment on Top 10 Continuous Integration Tools | List of Best CI Tools | scmGalaxy
continuous-integration-tools
Today we are present here with another interesting article which will help you to know about the best tools which are used for continuous integration in DevOps practices.
Continuous Integration has become a mainstream technique for software development. Which makes it mandatory to implement it in your software development lifecycle (SDLC). But implementation of CI required best selection of tools to achieve good results and there is still a confusion amongst beginners and even in vetrans of software industry while choosing the best tools. So keep reading, I have done some research and compile a list of CI tools which will definitely going to help you.
Before going further, let’s first see what is Continuous Integration?
Continuous Integration is a practice in DevOps software development process which improves the quality of the code. In this practice all the developers who are related and working on the project integrate there codes into a central repository frequently for several times in a day. After which automated build and automated tests run, which verify each integrations in the repository. The main objective of the continuous integration is to provide rapid feedback when any defect is found in the code base and correct it as soon as possible.
Now we know about continuous Integration but one question arises here, Why we do Continuous Integration?
So, Now let’s see the benefits of CI
  • 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.
So, these are the major benefits of CI. Now back to the point and purpose of this article, as I said earlier continuous intergation needs various tools to implement the process and choosing amongst the available tools for your purpose can be a daunting task, especially when you are going to select for the first time.
So, without further wasting any time let’s check out the top 10 Continuous integration tools.

1. Jenkins

jenkins
Jenkins is a Java written Continuous Integration tool, which was initiated as the fork of Hudson after conflict with oracle. It is a cross platform tool which allow GUI interface and console commands configuration. It available under MIT license which make it free to use. It supports rich plugins that integrates with virtually every existing software configuration management [SCM] or builds tool.

Features:- 

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

2. TeamCity

teamcity

 

TeamCity is one of the mature and wise java based continuous integration server which is belongs to JetBrains labs. It is available in free and paid license for users. It’s free version offers almost all the features but for up to 20 build configurations and 3 free Build Agents. Teamcity also supports different tools and frameworks and also it’s available with wide variety of plugins. It’s also support .Net features which makes it suitable for .Net projects.

Features :- 

  • 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

3. Travis CI

travis ci

 

Travis CI is an open source continuous integration tool which is written in RUBY. It’s easily get sync with GitHub. It’s supports platforms like Linux, Mac or iOS and also supports many languages in which Node js, php, Xcode, python, java, are few of them. It also performs parallel test runs using their great APIs and command line tools.
  • 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.

4. Microsoft Team Foundation Server

tfs
Team foundation server which is also abbreviated to TFS is a product of microsoft. It is a collaborative tool that consists the code repositories, continuous integration, and bug or task tracking. TFS perform in environment like Eclipse, Xcode, Visual Studio or in Git client. It’s also support languages like Python, C#, HTML, Java and various others too. It is available for free downloading but under trialware license.

  • 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

5. Bamboo

bamboo

Bamboo is also one of the top continuous integration tool which is developed by Atlassian. This is available with free trial license. Bamboo is written in Java and it is easily works with JIRA & Bitbucket. It’s also allow you to import jenkins data to Bamboo easily. Bamboo also supports others tools like AWS, Amazon S3, Ant, Docker, codeDeploy, Maven, Git & SVN.

Features:- 

  • 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

6. UBuild-UDeploy-URelease

ubuild-udeploy-urelease
UBuild-UDeploy-URelease is also known as Urbancode deploy is a collaborative product of IBM. It provides continuous delivery, self-service, speedy feedback and progressive updates within the agile development and automates the applying deployments during a consistent manner. With urbancode You can systemise the changes you pushed on servers, tiers and components and also restore the applications.

Features:- 

  • 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

7. Go CD

go cd


Go CD is a free of charge (excluding commercial support) tool written in Java and Ruby which belongs to ThoughtWorks. This tool works on Linux, Windows and Mac Platforms. It’s also supports many languages but which makes it stand out among-st the tools is the Pipeline concept which makes build process easy and it eliminate the file-handle leak errors and fix the OOM on agents when parsing large xml test artifacts.

Features:- 

  • 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
8. GitLab CI

gitlab ci

GitLab CI is an open source and also comes with commercial licesnse continuous integration tool. It belongs to Gitlab inc. which is written in Ruby and Go. This tool support platforms like Windows, OSX , Linux, Unix and various others which supports Go. Gitlab work with languages like Java, PHP, Ruby, C and with various others too.

Features:- 

  • 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

9. CircleCI

circleci
CircleCI is also belongs to Gitlab Inc, free and paid with trail option which runs in any environment like cross platform mobile app too. Circle ci supports languages such as Python, Ruby/Rails, Node.js, PHP, Haskell, Skala and Java. This tool is scalable which minimize the errors and improves application quality. Circle CI also supports Docker.

Features:- 

  • 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

10. Codeship

codeship

Codeship is also an powerful hosted CI tool which is available with free and paid support options. This tool is very easy to set up and it automatically deploy the passed tests results. This tool works on GitHub and Bitbucket, but you can use it with docker platform too by opting packages. This tool support langusges such as Java, PHP, Ruby (Rails), Node.js, Python, and Go.

Features:- 

  • 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
So, this is my list of top continuous integrations tools. Hope my efforts will help you in your Continuous integration process. One more thing, I would like to add here is that, if you want to learn the continuous integration process or you need support to get started with these tools in your work environment than scmGalaxy offers support from industry experts. And, If you think that any others tools deserves place in this list than feel free to share with us in the comment section.
Tagged : / / / / / / / / / / / / / / / / / / / / / / /

DOT NET Build and Release Training | Build and Release DOTNET Course

by scmgalaxy KTrainingLeave a Comment on DOT NET Build and Release Training | Build and Release DOTNET Course

 

About the Build and Release Dot Net Course
This Training is specially designed for the engineer who wants to excel their career in Build and Release and DevOps domain using Microsoft Platform in DO NET. We are using tools like TeamCity and Jenkins for CIs, apart from MsBuild, NAnt, Octopus, Nuget and Puppet.
Course Objective – Build and Release
After the completion of Build and Release Dot Net course at scmGalaxy, you will be able to :
  1. Understand the need for Build and Release Dot Net and the problems it resolves.
  2. Learn about the common Infrastructure Servers, Scalability and Availability
  3. Implement Automated Installations and Deployments
  4. Understand Performance and basic Security for Infrastructure
  5. Implement Virtualization Concepts
  6. Understand the need and concepts of Monitoring and Logging
  7. Understand the Continuous Integration and Deployment (CI/CD)
  8. Learn various Build and Release Dot Net tools TFS, Puppets, Jenkins, Nagios, Docker, GIT, etc
Who should go for this course?
This course is a foundation to anyone who aspires to become a Build and Release Dot Net Engineer, a Engineer in the field of Enterprise Infrastructures. The following professionals are the key beneficiaries of this course :
  1. DevOps Engineer
  2. Build and Release Engineer,
  3. AppOps Engineer,
  4. Site Reliability Engineer
  5. System Administrator
  6. Operations Engineer
  7. Automation Engineer
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
Tagged : / / / / / / / / / / / / / / / / / /

Build Configuration Templates in Teamcity | Teamcity Guide

by scmgalaxy KBuild Management & ToolsLeave a Comment on Build Configuration Templates in Teamcity | Teamcity Guide

build-configuration-templates-in-teamcity

Going meta with Meta-Runners in TeamCity

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.

Note

While templates can be used to create and maintain build configurations that are very similar, Meta-Runners can be used across build configurations that perform the same build steps. Moreover, a build configuration can only be based on one template, but it can make use of multiple Meta-Runners.

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.

Note

Deploying to Heroku using remotes needs the ssh keys to be set up on the agent. The example used here just illustrates Meta-Runners and may not be ideal for production use.

As mentioned in Chapter 6, TeamCity for Ruby Projects, we can use a gem such as heroku-headless (https://github.com/moredip/heroku-headless).

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:

Going meta with Meta-Runners

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.

Tip

A Meta-Runner is essentially an XML configuration (much like most TeamCity configurations) that can be edited directly from the web interface.

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

Going meta with Meta-Runners

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:

Using Meta-Runners

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:

Using Meta-Runners

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

Tagged : / / / / / / / / /

Going meta with Meta-Runners in TeamCity

by scmgalaxy KTeamCityLeave a Comment on Going meta with Meta-Runners in TeamCity

teamcity-meta-with-meta-runners

Going meta with Meta-Runners in TeamCity

Official Reference – https://confluence.jetbrains.com/display/TCD9/Working+with+Meta-Runner

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.

Note

While templates can be used to create and maintain build configurations that are very similar, Meta-Runners can be used across build configurations that perform the same build steps. Moreover, a build configuration can only be based on one template, but it can make use of multiple Meta-Runners.

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.

Note

Deploying to Heroku using remotes needs the ssh keys to be set up on the agent. The example used here just illustrates Meta-Runners and may not be ideal for production use.

As mentioned in Chapter 6, TeamCity for Ruby Projects, we can use a gem such as heroku-headless (https://github.com/moredip/heroku-headless).

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:

Going meta with Meta-Runners

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.

Tip

A Meta-Runner is essentially an XML configuration (much like most TeamCity configurations) that can be edited directly from the web interface.

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

Going meta with Meta-Runners

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:

Using Meta-Runners

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:

Using Meta-Runners

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

Tagged : / / / / / /

TeamCity Training | TeamCity Course | Online | Classroom | India

by scmgalaxy KTrainingLeave a Comment on TeamCity Training | TeamCity Course | Online | Classroom | India

teamcity-training

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

Tagged : / / / / / / / / / / / / / / / / / /

Bamboo Vs TeamCity Vs CruiseControl – Continuous Integration Expert Review

by scmgalaxy KTools ComparisonLeave a Comment on Bamboo Vs TeamCity Vs CruiseControl – Continuous Integration Expert Review

bamboo-vs-teamcity-vs-crui

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

Tagged : / / / / / / / / / / / / / / / / / / / / / / / / / / /