TeamCity integrates with Visual Studio Online and Azure – Special offer for MSDN subscribers

teamcity-visual-studio-online-vsoA large number of TeamCity users are working with Microsoft technologies and platforms such as Visual Studio Online and Azure, both fantastic tools in their respective areas. We are really excited to announce several new integration points between TeamCity and these tools!

Special TeamCity Offer for MSDN Subscribers

Today we are launching a special offer in partnership with Microsoft. All MSDN subscribers are eligible for a 50% discount on new TeamCity Enterprise licenses. Visit the MSDN special offers page to see the details and apply for the discount.

This is the first time TeamCity offers such a bargain for its commercial licenses. If you were planning on upgrading to Enterprise, this is definitely the right time to do it!

Building from Visual Studio Online Source Control

Visual Studio Online provides excellent source control, with support for Team Foundation Version Control and Git. TeamCity supports building projects that are hosted on Visual Studio Online and provides a powerful and comprehensive continuous integration story because of its advanced features to automatically run builds for feature branches,  automatic merge and many others.  Read more in the dedicated blog post on TeamCity and VSO source control.

Work Item Integration

Continuous integration becomes more powerful when we have full traceability from source control to builds to issue tracking and vice-versa. The Visual Studio Online Work Items plugin gives us a direct link between the build and version control history in TeamCity and the Work Items that were associated with them.

Work Item integration with TeamCity

Team Room Notifications

Quick feedback on changes and communication are the corner stones of agile teams. Visual Studio Online users can collaborate in a Team Room and discuss what is going on in the project. With the Visual Studio Online Team Rooms plugin for TeamCity, the build server becomes a member of our team by posting notifications around builds to the team room.

VSO notification

Elastic Cloud Build Agents on Azure

Very often it is difficult to predict the load on build agents, for example during releases. One minute we need only one or two build agents, the next minute we have 50 builds queued up. Using the elastic nature of cloud platforms like Microsoft Azure, we can scale out our build farm when needed. The TeamCity Azure plugin provisions and deprovisions virtual machines when needed, perfectly aligning capacity demand of our build farm with its running cost.

If you’re using or planning to use Visual Studio Online together with TeamCity, give these plugins a try! They provide great interoperability between both products, providing a best-of-breed solution for development teams. Keep an eye on this blog, as we’ll be writing more about these integrations in the coming days.

And remember: all MSDN subscribers are eligible for a 50% discount on new TeamCity Enterprise licenses. Visit the MSDN special offers page to see the details and apply for the discount.

Happy building!

Posted in Features, News & Events, Partner | Tagged , , , , | 3 Comments

Introducing TeamCity Azure plugin – Run builds in the cloud

Microsoft AzureIn a large TeamCity setup with many projects, it’s often very difficult to predict the load on build agents, for example during releases. One minute we need only one agent to be running, the next minute we need 50. Not to worry! TeamCity supports scaling out builds to Amazon EC2, and starting today, also Microsoft Azure!

For each queued build, TeamCity first tries to start it on one of the regular, non-cloud agents. If there are no regular agents available, TeamCity finds a virtual machine or virtual machine image with a compatible agent and starts it on Azure. TeamCity ensures that the configured maximum number of instances is never exceeded. Let’s have a look at how we can get started with a Windows or Linux build agent farm on Microsoft’s cloud platform.

Installing the TeamCity Azure plugin

First things first, of course. The TeamCity Azure plugin is not bundled and therefore has to be installed on our TeamCity server. It is compatible with TeamCity 8.1 and the EAP of TeamCity 9. Shutdown the TeamCity server, download the latest version of the plugin from our build server and copy the downloaded zip archive to the <TeamCity Data Directory>/plugins directory. Next, start the TeamCity server again and verify the plugin was loaded correctly from the Administration | Plugins List page.

Plugins List

Once that’s done, we can get started with creating a virtual machine or virtual machine image for our build farm.

Preparing a Virtual Machine (Image) with TeamCity Agent

We’ll need to create a virtual machine (image) on which our builds will run. In short, we need to create a Windows or Linux virtual machine:

  • on which all build prerequisites are installed (e.g. Java, .NET, Visual Studio SDK’s, …).
    Tip: When you plan on testing this plugin for .NET builds and have an MSDN-enabled Azure subscription, this is a step that can be quickly done by creating a virtual machine from a readily-available Visual Studio image.
    Visual Studio MSDN image on Azure
  • on which a TeamCity build agent is installed and configured.
  • on which we’ve opened port 9090 (or a port range in case we want to have TeamCity create virtual machines for us) in the operating system firewall and as an endpoint on the Azure load balancer. This is required to enable two-way communication between TeamCity server and the agent.
  • with which we have tested the connection between the TeamCity server and the build agent.

If we want TeamCity to create virtual machines for us, we will also have to create a generalized image of he virtual machine we’ve just created. Check the full documentation for a detailed list of steps involved in creating a build agent virtual machine (image).

Configure the TeamCity Azure plugin

Once we have the plugin installed and have a virtual machine (image) our builds can run on, we can configure the TeamCity Azure plugin. From the TeamCity | Administration | Server Administration | Agent Cloud page, we can create a cloud profile with the “Azure” type.

We will need at least a name for our cloud profile. The Terminate Instance Idle Time is an important one to configure: it tells TeamCity how long an instance can be idle before it will be stopped. As Microsoft calculates costs based on the number of minutes a machine runs, it is recommended to adjust this setting according to our usual build length. This reduces the amount of time a virtual machine is running and thus, reduces the cost.

Create an Azure cloud profile

TeamCity will need two more things to be able to provision virtual machines on Azure: a management certificate and the ID of the subscription in which to deploy build agents. After downloading the publish settings, find these values in the downloaded XML files and paste them in the plugin configuration.

Clicking Add Image lets us specify the virtual machine (image) we want TeamCity to run. The TeamCity Azure plugin supports two modes of operation:

  • Start/stop, which starts and stops an existing virtual machine on demand.
  • Image-based, which creates and destroys virtual machines based on an image.

Let’s go with an image-based approach and provision up to 10 agents based on the TC-Agent image I’ve created. We have to specify the service in which we want to provision virtual machines. The service must be either empty or contain only a virtual machine deployment. It is recommended to create a new, empty service for this.

Next we can choose the VM size, as well as a username/password for the user that will be created during the provisioning process. Note that the password has to match Azure’s password requirements.

Run TeamCity agent in Azure

After adding the image and saving the cloud profile, TeamCity does a test start for them to learn about the agents configured on them. Once agents are connected, TeamCity stores their parameters to be able to correctly process build configurations-to-agents compatibility.

From now on, TeamCity will first try to start builds on regular build agents. If none are available, it will start compatible agents in Azure. We can see the running images from the Agents | Cloud page and optionally start/stop them as needed.

TeamCity agent running in Azure

Head over to the documentation for the TeamCity Azure plugin and give it a try.

Happy building in the cloud!

Posted in Features, FYI, How-To's, News & Events, Tips&Tricks | Tagged , , , , | 13 Comments

CI Tools Survey Prize Winners Announcement

Hello everyone!

We’d like to thank each and every of the 891 participants of our CI Tools Survey. It’s great to know that we’ve got such an active and responsive community! You really gave us food for thought and we do hope that it will help us make TeamCity your favorite tool ever!

Today we are happy to announce the three lucky winners of $300 Amazon.com certificates who were chosen randomly. So put your hands together for a round of applause for:

  • ThaGoob (Germany)
  • ceis estudiantil (Venezuela)
  • Albi (Greece)

We’ll send a personal email to each of the winners with details on obtaining the prize. In case your name is in the list, but you do not get information from us today, please give us a shout in the comments on this post.

Congratulations from all of JetBrains, and especially from the TeamCity development team!

And in case you missed the new TeamCity 9.0 EAP build – here is the download link – give it a try and let us know what you think!

Have a great weekend and happy building!

Posted in Uncategorized | 2 Comments

TeamCity 9.0 EAP2 – Clean-up in background, Perforce streams and more

Greetings, everyone!

The fall has clearly arrived at our neck of the woods with yellow and scarlet foliage, rains, first frosts and a rich apple harvest. And while almost everyone seems to be busy baking apple pies, our developers are tirelessly cooking the new TeamCity version, carefully weighing out and mixing all the best ingredients which nicely turned into this TeamCity 9.0 EAP2 build.

Regardless of the season and the temperature outside, you do want your server to be available 24/7 and this is exactly what we have been able to achieve by moving the build history clean-up to the background.

Besides, the work on synchronizing the project settings with version controls continues, and now you can store your settings in a Mercurial repository.

Our developers make an effort to improve TeamCity integration with different version controls:

    • This EAP release includes initial support for Perforce streams.
    • We also improved support for the Mercurial version control system and now, for example, you can enable mercurial extensions only in the repositories where they are required. Previously you had to to edit global mercurial configs on the server and agents, which was inflexible and could lead to performance problems: we know it from our own experience here at JetBrains: the ReSharper team is using the largefiles extension which in our case used to slow down the hg pull command significantly in repositories. After removing the largefiles extension, collecting changes time reduced to a few seconds compared to 10 minutes before.

This is by far not all – see our Release Notes for the complete list of the features and fixes in this new EAP version.

Download the build to try it in your test environment and remember that your feedback is most welcome and greatly appreciated!

Happy building!

Posted in Bugfix, EAP, Features, News & Events, Uncategorized | 2 Comments

7 Steps to Build a Database Deployment Pipeline with Red Gate and TeamCity, Webinar Recording

The recording of our October 2nd webinar with Alex Yates of Red Gate, 7 Steps to Build a Database Deployment Pipeline with Red Gate and TeamCity, is now available on JetBrains YouTube Channel.

In this practical demo, Alex Yates, Pre-Sales Engineer at Red Gate,  demonstrates how to set up continuous delivery for your SQL databases using TeamCityRed Gate’s SQL Automation Pack, and Octopus Deploy.

Below are select questions and answers from our webinar.

Continue reading

Posted in Uncategorized | Leave a comment

TeamCity and Visual Studio Online Source Control

Many teams are working with Visual Studio Online (VSO), a hosted Team Foundation Server that provides source control and issue tracking as a cloud service. While VSO comes with a build server as well, lots of developers prefer to use TeamCity for their continuous integration story because of its advanced features to automatically run builds for feature branches,  automatic merge and many others.

TeamCity supports building projects that are hosted on Visual Studio Online, the only thing we have to do is add a VCS root to our build configurations. Depending on the version control system used for the project (Git or Team Foundation Version Control – TFVC), this will be slightly different. Let’s have a look at our options.

Enabling alternate credentials

Independent from the version control system used, we will have to enable alternate credentials support on our Visual Studio Online account. Applications that work outside the browser, such as the git client or the command-line TFS client, require basic authentication credentials to work. By editing our VSO profile, we can set a secondary username that can be used for these scenarios.

After navigating to our VSO account portal, we can use the menu at the top-right to edit our profile. The Credentials tab lets us enable alternate credentials. After clicking Enable alternate credentials, we can set a secondary username and password we can use later on.

Visual Studio alternate credentials for TeamCity

After saving our changes here, we can proceed with connecting TeamCity to Visual Studio Online version control.

Connecting to Visual Studio Online Git

For teams embracing Git source control with Visual Studio Online, TeamCity setup is really easy. From the Administration section, we can create a new project from URL. Next, we can enter the URL to our VSO Git repository and provide the alternate credentials we’ve just set up. TeamCity will auto-detect we’re using a Git repository.

Create project from URL

Connecting to Visual Studio Online TFVC

Projects that are using Team Foundation Version Control (TFVC) can leverage TeamCity in their projects, too. The workflow to get started with a new project is the same: from the Administration section we can create a new project from URL, entering the URL to our Visual Studio Online project’s TFS path. This typically looks like https://accountname.visualstudio.com/DefaultCollection/$/ProjectName. For credentials, we can enter our Microsoft Account credentials, or use the alternate credentials created earlier.

Create TeamCity Project from Visual Studio Online

Note that for TeamCity versions < 8.1.5 and older versions of Team Explorer, the Microsoft Account name has to be prefixed with ##LIVE##\.

Creating the Build Configuration

Once we have connected to Visual Studio Online, TeamCity will try to identify potential build steps we can use. It will browse our repository and look for Visual Studio solution files, projects, batch files, NuGet packages that have to be restored and so on. We can use these automatic steps, or add our own to fine-tune our build process.

Auto-detectedbuild steps

When at least one build step is configured, we can start our build. It is possible to fine-tune our version control integration from the build configuration’s Version Control Settings. In here, we can configure what our branch structure looks like so that TeamCity automatically runs the build configuration for any feature branch we have. We can also modify the VCS Changes Checking interval and change when to check VSO  for changes.

Using a Trigger, a build can automatically be started when chenges are checked in to VSO. The VCS Trigger must be added to the build configuration to do this. Optionally, we can build for every single change, accumulate check-ins and so on.

Automatically start TeamCity build when changes checked in to Visual Studio Online

Many other triggers are available, such as the Schedule Trigger which starts a build at a given time. The Finish Build Trigger can start a build once another build has been finished. We can also monitor NuGet feeds and trigger a build when a given dependency changes.

TeamCity is a great companion to Visual Studio Online for many scenarios. Happy building!

Posted in Features, How-To's, Tips&Tricks | Tagged , , , , | 5 Comments

TeamCity 8.1.5 is out now

Greetings to all of you!

Did you know that TeamCity is approaching its eighth anniversary? In anticipation of this date, we have just released yet another update for TeamCity, version 8.1.5, containing about 50 bug fixes and enhancements!

We spent quite some time improving the performance of the Build Chains page and fixing other performance and usability problems; besides that, we knocked out some security issues in this build, so upgrading would be a really good idea!

Now TeamCity comes with the bundled Tomcat updated to version 7.0.55. Those making use of Teamcity’s NuGet capabilities will be interested to learn that you can specify additional command line parameters for NuGet.exe. All the more reason to upgrade!

Would you like to know more? Refer to our Release notes for the complete list of changes and download the latest TeamCity version! This release uses the same database format as other 8.1.x builds, so, should you run into any problems, downgrading to a previous 8.1.x version is absolutely painless.

Most likely, this is the last update for TeamCity 8.1.x before TeamCity 9.0 release in the late November, so soon you’ll hear more about our next milestone, TeamCity 9.0 EAP2!

Stay tuned and Happy building!

Posted in Blogroll, Bugfix, EAP, Features, FYI, News & Events, Tips&Tricks | 2 Comments

7 Steps to Build a Database Deployment Pipeline with Red Gate and TeamCity, October 2nd Webinar

Join us Thursday, October 2nd, 15:00 – 16:00 GMT (11:00 AM – 12:00 PM EDT) for our free webinar, 7 Steps to Build a Database Deployment Pipeline with Red Gate and TeamCity with Alex Yates of Red Gate.

Continuous delivery for databases brings speed, efficiency and predictability to your release cycle, by automating database deployments across a pipeline. Setting-up version control, continuous integration (CI) and automated release management can provide you with a steadier stream of reliable releases.

In this practical demo, Alex Yates, Pre-Sales Engineer at Red Gate, will show you how to set up continuous delivery for your SQL databases using TeamCity, Red Gate’s SQL Automation Pack, and Octopus Deploy. You’ll learn best practices for continuous integration, continuous delivery and automated deployments to set-up your own pipeline.

Space is limited, please register now. There will be an opportunity to ask questions during the webinar.

About the Presenter:

Alex Yates_squareAlex Yates has worked with database change management tools for four years, collaborating closely with users and dev teams along the way. As a pre-sales engineer, he gets to see a huge variety of server and dev environments, and helps folks solve their database development and delivery problems in whatever way works well for them. Ever the sharer, he also blogs about the lessons he learns: www.workingwithdevs.com.
Posted in Uncategorized | 9 Comments

Applied Automation TeamCity and NDepend

This guest blog post is from Wes McClure, Software Consultant and Founder of Full City Tech Co., a JetBrains Training and Consulting Partner. 

In Approaching Automation, I outlined a series of steps to follow to make worthwhile investments in automation. In the following example, I’ll show how to apply these steps to a software development process.

Inspecting code can provide valuable insight into improving the design of a system. Inspection tools are most valuable when they’re integrated with the environments that developers use to create software. They can provide instant feedback to improve, on the fly.

Inspection is also valuable as an analysis tool after the fact. One barrier to analysis is the time it takes to setup and inspect a code base. This process is ripe for automation so time can be spent analyzing results, not gathering them.

Wes McClure

Wes McClure, Software Consultant and Founder of Full City Tech Co.

But, blindly automating anything is as reckless as avoiding automation altogether.

Often, when discussing inspections, I find individuals wanting to inspect code bases every time a change is made to the system.

I’ll inquire how often do you perform this analysis currently and what do you do with the information? Often, I find there’s no methodical approach and sometimes inspection isn’t even a part of an existing process. It’s just something that someone said was a good idea.

Whatever the case, by stepping back and discussing how often the information is used and what it’s used for, we can begin to understand the value of automating inspections.

By challenging ourselves to understand why the information is valuable, we can determine the appropriate level of automation to improve.

Most teams are busy enough, they’ll be lucky to look at inspection results once a week. And, if they have to manually generate it, it’s much less likely they’ll even get around to it.

But, if inspection reports are automatically available on a weekly basis, they could invest more time in analyzing the results. And in turn, invest in acting on the results.

NDepend is a tool to inspect a .NET code base and provide actionable metrics to improve.

TeamCity is a platform to automate development processes, gather results and act upon them.

Let’s walk through the basis for automating inspections with NDepend and TeamCity.

Outline

First, we should outline the process.

NDepend is used to inspect a code base. This requires checking out the code, compiling it and then analyzing the results with NDepend.

Then, teams analyze the results for ways to improve.

And over time, they apply this insight to incrementally improve.

Eliminate the unnecessary

After outlining the process, it’s important to eliminate vestigial components. In the case of inspections, this is a matter of making a conscientious decision about what inspections are meaningful and what aren’t. Don’t just take everything out of the box. And, spend some time with NDepend to craft your own custom inspections.

Establish objectives

Next, it’s important to establish objectives. NDepend comes with the concept of rules. Reducing rule violations can improve the quality of a code base. For example, NDepend comes out of the box with rules that help detect breaking changes to software interfaces. It also provides rules to detect dead code which can hamper the longevity of software. Deciding on a set of rules to enforce may serve as a worthwhile objective.

Establish measures

Let’s say we want to reduce dead code in a system. Every system contains some amount of dead code. Some of it can be detected automatically. Measuring the current level of dead code in a system and setting goals to reduce it serves as a progress indicator.

Establishing value

What if your system is comprised of ten percent dead code? What would it be worth the get that to five percent? What about one percent?

Make a decision

Everything above becomes the basis with which one decides to automate, or not automate, inspections of dead code or any other aspect of a system.

I always recommend a margin of two or three times the potential cost. That way you have room to absorb the unknown.

Automate it

There’s no better way to describe automating it than to show you:

Reflect

Over time, use the information you capture in TeamCity from the output of NDepend to see if efforts prove worthwhile.

Not everything is so easily quantifiable. Nonetheless, you can start to see how you can apply a methodical process focused on value to scientifically improve your development process.

The original post was published September 11th, 2014 on www.wesmcclure.com. 

Posted in How-To's, Partner | Tagged , , , | 1 Comment

Join our CI Tools Survey and Win a Prize!

Hello everyone,

We are researching the ecosystem of the CI tools that you are using and we’ll appreciate if you could help us with this. You surely have got plenty of expert knowledge when it comes to using different CI tools and we’ll be happy if you shared your opinion and experience with us by spending 10-15 minutes on completing our survey. Of course, we hope that TeamCity is your favorite tool, but even if it’s not, we would like you to participate in the survey and help us understand what we could do to make TeamCity better.

Our survey is designed to be completed in one sitting, which means that once you close it, you won’t be able to go back to the questions you’ve already answered. Ready, set, go! We guarantee that all the information you provide will be kept confidential.

In case you think you’ve got better things to do, think twice! There is a bonus – those who complete the survey will be eligible for one of three $300 Amazon.com certificates. Don’t wait for long – get started with the survey!

The prize winners will be named on October, 10. Check your email to find out if you are one of them! There will also be an announcement in our blog and Twitter!

Stay tuned for the latest TeamCity news and happy building!

Posted in Uncategorized | 2 Comments