Setting up TeamCity as Symbol and Source Server

When debugging applications with various Microsoft tools, you need to have symbol and source information, provided by the Microsoft Symbol Server and Source Server technology.

It’s been some time since we created a plugin which allows using TeamCity as a symbol and source server, and now, after some bug-fixing has been done, we decided we are ready to announce it officially.

So please welcome the TeamCity Symbol Server plugin! With just a few mouse clicks you can set up TeamCity to index the .PDB files and binaries for all your .Net applications and, once the plugin is enabled, you can easily debug applications or analyse crash dumps: your debugger will be able to automatically retrieve the required symbol files and to download the sources of the appropriate version for shared libraries referenced by you application, if, say, these modules are developed by a different team in your company and shared between several projects.

Prerequisites

To set up TeamCity as a Symbol and Source server, we assume you have the following:

  1. TeamCity server 8.0.3 or later with a project and build configuration to build your application.
  2. Debugging Tools for Windows on the agent machine(s) where your application is built (can be installed using this link).

Now all you need to do is enable the TeamCity Symbol Server plugin in TeamCity and set a number of options in your debugger.

Download and install the plugin

  1. Since the plugin is not bundled with TeamCity, download the required version from here and install the plugin as usual.
  2. Now enable the symbol server on the Administration| Integrations| Symbol Server page. You will see that it is referenced by the following URL < TEAMCITY_SERVER_URL>/app/symbols. This is the URL to be used in the Visual Studio or windbg settings.

The permissions required to access symbols and sources via the TeamCity server are default for the project developer role, and the indexed data can be accessed in both public (not requiring authorization) and authorized modes.

Tune the build configuration settings

Next we need to add the Symbol Files indexer build feature to our build configuration settings:

AddBuildFeature

Once you add the feature and save the settings, all PDB files published as build artifacts of this configuration and all related sources will be indexed.

Next let’s take a look at the files we are publishing as build artifacts. In this setup we are building an application referencing a dll and we are publishing a .zip archive which includes the application along with the PDB file and the library:

Artifacts

The plugin can handle the PDB files published separately or packed using the TeamCity artifact publishing rules.

That’s it! Now we can run the build. When the build is finished, the build log shows that source indexing was performed and symbols files signatures were collected and written to an xml file:

buildLog

The file containing symbol files signatures is published internally and is available in the TeamCity internal artifacts under .teamcity\symbols:

publishedArtifacts

Set the debugger options

Now we need to set a few options in the debugger, Visual Studio in this case:

  1. In the Debug menu, select Options and Settings, in the General section uncheck the default Enable Just My Code and Require source files to exactly match the original version options.
    If you do not have the source code on the local machine or the .pdb file does not match the source code, you can use Source Server to find and download the sources: select Enable source server support and check all the options in that section.VSDebugOptions
  2. During a debugging session in Visual Studio, the debugger automatically loads symbol files that are located in the project directory. To specify TeamCity as a symbol server, select the Symbols section on the left and add the TeamCity symbol server URL ( from the Administration| Integrations| Symbol Server page) to the list of symbol file locations.
    On the Symbols page you can also filter out or specify modules that you want the debugger to automatically load symbols for. These settings can be changed manually when you are debugging.VSSymbolSources
  3. Save your changes.

Now your debugger will load the required symbol and source files from TeamCity enabling you to successfully debug applications and crash dumps!

Try out the TeamCity Symbol Server plugin and let us know what you think!

Happy building and debugging!

Posted in Features, FYI, How-To's, News & Events, Tips&Tricks | Leave a comment

Dashboarding with TeamCity

Data visualization has never been so popular as it is today. The human eye and brain are so powerful that they catch information and detect patterns on-the-fly: just in a blink of an eye you can extract a lot of information and make a decision on what to do next. Dashboards are everywhere for business and fun.

Here at JetBrains we have a ‘KitchenTV’ project – a set of pages rotated on several large screens in the office. In the beginning they were charts with data from our issue tracker, lists of tweets, nice widgets with weather information for all JetBrains office locations. Then the real-time visualization of the daily purchases was added – every time one of our products is bought, a ball of the corresponding color falls down forming several nice different-sized and -colored mountains at the end of the day, which are a lot of fun to look at.

Now we decided to contribute to this project and add some useful information from our internal TeamCity server for the common benefit, and we thought you might be interested too, so here it is.

At the moment we have two widgets. The first one shows the list of assigned investigations – so your colleagues can see your involvement in problem digging and fixing.

Screen Shot 2015-02-09 at 14.35.37

The next widget displays the list of most recent VCS commits. It means that anyone can quickly understand what their teammates are working on.

Screen Shot 2015-02-13 at 14.45.16

The technologies behind these widgets are simple: REST + AngularJS, so it is basically the static content. If you want to use the widgets with your own TeamCity, you can choose one of two options:

  • install the TeamCity.Widgets plugin to your TeamCity or

  • install the TeamCity.StaticUIExtention plugin and add widgets content as a folder under the StaticUIExtention config root. Once you restart your server to make TeamCity.StaticUIExtention work, you can update the static content without further restarts.

The code of the plugin is open and available on GitHub.

Your feedback is welcome: in the comments here or in our issue tracker.

Enjoy the widgets and happy building!

Posted in Uncategorized | 1 Comment

TeamCity 9.0.2 is here

Greetings, everyone!

Today we are announcing the release of TeamCity 9.0.2!

This bugfix is rather important as it addresses about 100 issues. The fixes affect:

  • backup performance (TW-39612)
  • LDAP synchronization (TW-39589)
  • mechanism of applying changes in versioned settings (TW-39519, TW-39553)
  • recognition of Visual Studio Online URLs on the “create project from URL” page (TW-39730)

In addition, we updated the bundled JetBrains dotCover to version 3.0, and added the ability to reorder custom charts on the “Project Statistics” page. See our Release Notes for the full list of fixes.

As usual, bugfix releases do not change data format, so do not hesitate to upgrade if you are already running TeamCity 9.0!

Download the build and follow the upgrade instructions!

Your feedback will be greatly appreciated!

Happy building!

Posted in EAP, Features, News & Events, Tips&Tricks, Uncategorized | 1 Comment

What’s New in TeamCity 9, Webinar recording

The recording of our January 21st webinar with Wes Higbee, What’s New in TeamCity 9, is available on JetBrains YouTube channel.

In this webinar, Wes goes over the new features of TeamCity 9, namely: rearranging projects with Project Import; storing settings in VCS; creating and editing Custom Charts; running builds in Cloud Agents; as well as some other improvements.

We were glad to see tons of questions from the attendees. Below are select Q&A from the webinar.

Continue reading

Posted in Features, How-To's, Webinar | Leave a comment

How Groovy uses TeamCity

This guest post is brought to you by Cédric Champeau, a Senior Software Engineer working on the Groovy language at SpringSource/Pivotal.

NB: starting today Groovy is looking for a new home.

Upgrading the continuous integration chain

For several months now, the Groovy language has been building a new continuous integration architecture based on TeamCity. We’re running it on a dedicated server sponsored by Jetbrains. One of the key reasons for moving to a dedicated server was the long feedback loop that we had on the Codehaus infrastructure and that classic open-source project CI infrastructures like Travis, based on slow cloud based instances offer: as an example, a minimal build on Travis took as much as 45 minutes. It may sound reasonable for a language like Groovy, but considering that the same build takes around 5 minutes on a recent laptop, there’s something very wrong. And there’s more than a single build to do:

The Groovy project has for example very strict requirements in terms of compatibility with several JDKs. We are testing Groovy against multiple versions of the JDK:

  • OpenJDK 5, for any Groovy version before 2.2
  • OpenJDK 6, the minimal JDK version for Groovy 2.2+
  • OpenJDK 7, with two different runtime versions: legacy and invoke dynamic
  • OpenJDK 8, with the same runtime versions as JDK 7

In addition, we test Groovy against early release versions of OpenJDK 7, 8 and even 9! We do that to report bugs to the OpenJDK team before new versions of the JDK go out in the wild. It has become more and more important lately since JDK 7 and the advent of invokedynamic: we have seen many buggy releases of the JDK breaking Groovy, so we really had to find a solution to avoid this as much as possible.

teamcity1

In addition to the combination of JDKs to be tested, Groovy is a widely used language, meaning that we have to support multiple versions. In particular, bugfixes are often backported on multiple branches. This means that we have more than one branch alive. Those days, we maintain Groovy 2.2.x, Groovy 2.3.x, Groovy 2.4.x and 2.5 is coming.

Last but not least, pull requests from the team or the community need to be pre-tested, increasing the combination of builds that we need.

For all those reasons, running TeamCity on a dedicated server looked like the best solution we found. It was also in particular important because TeamCity has the concept of a build agent. Build agents are important because they allow increasing the build capabilities externally. We haven’t done it yet, but one of the key aspects that made us lean towards TeamCity was the ability to build a group of “community driven” agents that would let us test Groovy on a wider variety of environments. In particular, the current builds are all based on a Linux x64 box, but Groovy needs to run on more than that: Windows, Mac OS, …​ All those environments need to be tested, but are not, because of the lack of build resources for that. This means that in the current architecture, we only rely on some community members who build on Windows or Mac OS to tell us if a build works or not. But we know that with TeamCity, we have a way to improve the situation in the future.

teamcity2

So imagine that each commit on the Groovy project needs to be tested on a combination of JDK, branch, environment, plus pull requests. This requires a lot of work, but TeamCity greatly simplifies this. In particular, the branch combination is reduced to simple configuration : on a build plan for JDK 7 for example, we can choose which branches need to be built. That dramatically reduces the effort needed to have a proper CI toolchain working.

From building to releasing

Another aspect of choosing TeamCity was the ability to simplify the release process. Before the new CI infrastructure was setup, releasing a new Groovy version was a bit complex. It involved building locally, checking the build, creating a tag, pushing the tags on VCS, uploading the distribution through WebDAV, or even the documentation through WebDAV. Last but not least, we also had to take care of synchronizing with Central through the Codehaus repository. Literally, it took hours. Releasing a Groovy version could take as long as a full day.

Since we migrated to TeamCity, we took advantage of using Gradle and Bintray to simplify the process. Using the Artifactory plugin and some configuration, releasing a new version of Groovy is as easy as filling a form in TeamCity.

teamcity3

Everything is built on the CI server, packaged, uploaded to Bintray and synchronized with Central using a single click. Lately we even added support for GVM directly in the release process on TeamCity, meaning that a new Groovy release is automatically promoted on GVM! There is still some manual process involved (for example, the CI server will not decide for itself if a build is considered a major version or not, nor will it automatically update the website to announce a release, or close JIRA versions for us). But what is interesting is that the overall process can be completed in less than an hour, including building, testing, and uploading. It’s a huge win.

teamcity4

A Groovy plugin for TeamCity

Interestingly, automating the release process soon required capabilities that TeamCity didn’t have out of the box. For example, notifying GVM, cleaning artifacts produced by pull requests, uploading the distribution to Bintray, calling the Artifactory REST API, …​ All those required scripting capabilities. For that reason, we developped a plugin for TeamCity which allows writing a build step as a Groovy script. The plugin gives access to a lot of information available in the build, like the build number, the branch name, etc…​ allowing us to trigger specific behavior based on that contextual information. For example, building all those branches on multiple JDKs is very nice, you soon realize that you are filling the disk with artifacts that you don’t want to keep. Unfortunately TeamCity will not let you have custom cleanup rules based on particular variables of a single build configuration. In our case, we wanted to remove the artifacts only for branches built from pull requests, and that is done through a Groovy script used as a build step.

Conclusion

In conclusion, we can say that we are very happy with the current status of our continous integration toolchain. We went as far as being able to release directly from the CI server, allowing us to dramatically reduce the errors related to a long, unfriendly human process, as well as dramatically improving our feedback loop (multiple JDKs, pull requests, …).

While the process can certainly be improved, for example by adding support for adding community build agents, doing it with TeamCity was very easy, so we’re very happy that we chose it!

Posted in Blogroll, Guest post, Partner | Leave a comment

What’s New in TeamCity 9, January 21st Webinar

Join us Wednesday, January 21st, 12:00 PM – 1:00 PM EST (17:00 – 18:00 GMT) for our free live webinar, What’s New in TeamCity 9 with Wes Higbee.

In this webinar, Wesley Higbee will go over some of the new and exciting features of TeamCity 9.0. He will demonstrate rearranging projects among servers with Project Import; working with Versioned Settings; creating and configuring Custom Charts; running builds with Cloud Agents, and other improvements in TeamCity.

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

About the presenter:

Wes McClureWes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies rapidly deliver high quality software to delight customers. He has a strong background in using Continuous Integration with TeamCity to bring quality to the table.
Posted in Uncategorized | Leave a comment

TeamCity 9.0.1 update is out

Greetings everyone!

TeamCity 9.0 is your 24/7 build engineer and our developers are unstoppable as well even during the holiday time! We thought we’d make you a small gift – a new bugfix release just before the New Year’s Day – and here it is: TeamCity 9.0.1 is available!

Thank you for taking time to report issues to us! Build 32116 addresses over 70 problems related to different functionality, including some improvements in project import and the fix for the issue with Groovy plug. For the full list of fixes take a look at the Release Notes.

Download the distribution from the JetBrains site. We recommend upgrading your server to this version: as usual, this update does not modify the data format, so rolling back to 9.0 is possible at any time!

Happy building and happy New Year!

Posted in Bugfix, EAP, Features, FYI, News & Events, Tips&Tricks | Leave a comment

Case study: TeamCity in Devbridge

This guest post is brought to you by Arunas Paskevicius, Web Developer at Devbridge Group. Based on the original CI with TeamCity Server“ post in the Devbridge blog.

Pre-TeamCity

A few years ago, most of our projects were just plain .NET web applications, and using one CI server (CruiseControl.Net) was enough. But as the company grew, so did our client base, and we realized not everyone wanted their projects to be written in C#. We started offering solutions created with PHP, NodeJS, Objective-C, Java and other languages. We also began using other tools for CI. For instance, we used Jenkins, and it ended up causing some problems.

The first problem was that some teams used CC.NET, while others used Jenkins. Sharing reusable build steps was problematic, because they were either “shell scripts” or CI application dependent configurations, not to mention we were dealing with different OS installations (Windows, Linux, OS X) on each of our CI machines.

The second problem was the usage balance between our CI machines. Some machines were used for running development and testing builds, others were used for deployment. For us, development builds occur frequently, so the machine responsible for this was always at max capacity while the production build machine wasn’t used nearly as much.

Deciding

After a frustrating time, we decided that we needed a single CI environment where we could reuse our existing CI machines. This would allow for a painless transition from other CI software.

We took Jenkins, Go CD, Atlassian Bamboo and JetBrains TeamCity and installed them on our test machine for comparison. Next, we created build configurations for already existing projects and checked for the following:

  • Simplicity of creating a build
    To move everyone from their current CI software to the new one, we wanted it to have a simple and clear way of creating builds so that the learning curve would be as low as possible.
  • Build reusability (templates, etc.)
    A lot of our projects use mostly the same build steps, so we need a way for creating templates and other ways of reusing those configurations.
  • Scalability
    We wanted our CI machines to be easily managed, added and balanced for our builds. The ability to intelligently pick the right machine for the build was necessary.
  • Active Directory support and role management
    At Devbridge Group, we use Active Directory to manage user accounts, groups and permissions. The CI software that we chose had to support authorization and, if possible, groups.
  • Ease of configuration and the overall look and feel
    Using an ugly piece of software should be a thing of the past. We wanted the software to be easy to understand, aesthetically pleasing and responsive.
  • REST API
    We needed the software to have a RESTful API so that we could connect it to our other monitoring software, re-run builds and so on.

Choosing TeamCity over others

The reason we picked TeamCity was because it had the best results for our necessary requirements.

  • Simplicity of creating a build
    Creating builds in TeamCity was a breeze. TeamCity came bundled with most of the tools (runners) we needed for C# and JAVA projects. To create the build steps, we just needed to select a runner in correct order with one or two additional parameters. For PHP we just downloaded “meta runners” from the official JetBrains GitHub repository and created build steps. Additionally, we were pleased that it’s possible to create artifacts from a build and then use it as a Report page. For example, code coverage.
  • Build reusability
    TeamCity has templates that make it possible to copy build configurations from one project to another. It’s possible to create beautiful, reusable templates and add configuration parameters so that when you create a new build from the template, you can specify certain data: build.xml location, GIT tag prefix and so on.
    Another great feature is the meta-runner. It allows the user to create smaller templates for a specific sequence of build steps. For example, you can create a Heroku deployment build step sequence, then extract them all into a single runner, and use it in other templates or even share it with the world (like JetBrains did with the meta-runner power-pack).
  • Scalability
    TeamCity has agents that can be installed on different machines and will then connect to the central CI server software. The central software manages which agent will be used for each build. Additionally, you can define requirements for the agents to use. You can achieve this by using the parameters provided by each agent (you can also add your own).
    If you have more than one agent assigned, then your builds will be intelligently divided among those agents and the agents that don’t meet your requirements will be automatically skipped.
  • Active Directory support and role management
    This was the first thing we actually checked for. We were pleased to find that TeamCity supports both AD user and group synchronization. This made our lives easier because we could assign specific roles for specific groups.
    The overall user and role management is some of the best we’ve seen in CI.
  • Ease of configuration and the overall look and feel
    TeamCity has pretty simple configurations. Most of them, apart from LDAP, were done in a good-looking admin panel on the main CI server, eliminating the need to dig through a pile of XMLs or run through unclear lists of data.
  • REST API
    TeamCity comes with a REST API that is well documented and has a lot of action calls that can be used in your own software: triggering/stopping particular builds, getting build test information and event triggering a whole CI server and backup.

Half a Year with TeamCity

Since we started using TeamCity, creating and managing builds became significantly easier. We already have templates and meta-runners for creating new projects, and we are no longer divided by using separate software to achieve the same results. Additionally, we’ve eliminated the problem of having some CI machines idle while others are maxed out.

Overall, we think that TeamCity is a powerhouse that has strong features for JAVA and .NET projects. It also allows simple creation of additional runners and templates for any language and platform you might choose.

devbridgeDevbridge Group is an international software design and development company that builds comprehensive, custom solutions for enterprise mobile and web. Devbridge combines engineering expertise with elegant design aesthetic to deliver exceptional results for leaders in the manufacturing, healthcare, financial services and retail industries.
Devbridge Group produces more than 100,000 engineering hours annually, building custom cloud-based and mobile solutions. Long-term partnerships with Devbridge are built on trust and transparency. The company follows a streamlined agile process, is committed to Responsive Design, and always pursues excellence.
Posted in Guest post, How-To's, Partner | Leave a comment

TeamCity 9.0: Best for Pandas

Winter releases of TeamCity are practically a tradition: we lovingly released TeamCity 8.1 this year just before St. Valentine’s day and now we really cannot think of a better way to end the year and celebrate Christmas than to present you with a brand-new TeamCity 9.0! Please give a welcoming round of applause for TeamCity 9.0 which has just been released!

With the server clean-up in background, TeamCity 9.0 finally has zero maintenance downtime which is great news for distributed teams, who no longer need to worry about scheduling the clean-up.

Besides, the new version comes with the ability to move projects between TeamCity servers preserving the project data and changes history as well as user profiles, and all of this is done right from the TeamCity web interface. We hope you’ll love this feature for its clarity and ease of use:

Another significant addition is storing project settings in version control – Git and Mercurial in this release. Keep track of your settings the same way you do with the source code:

There is so much more – see our What’s New and Release Notes!

Download TeamCity 9.0 and start enjoying the benefits of the new version immediately!

Oh, and if you are wondering about the title, find out why TeamCity is best for you and pandas on our web site!

Merry Christmas and happy building!

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

TeamCity evolution in the past 5 years

Dear TeamCity users!

Every new TeamCity release brings lots of changes, and oftentimes we are not sure how successful they will be, or they might seem minor at the time. This is especially noticeable if we come across an old TeamCity version and, looking back, we realize how accustomed we are to many of the features that once were a novelty. So today we decided to review the evolution of our CI server and remind you of the most significant features brought to you by the releases in the past 5 years.

Now we easily create projects in TeamCity by simply giving it a URL – the feature is barely a year old, it came with TeamCity 8.1 in February of 2014:
create_project_from_url

When you look at the internal JetBrains TeamCity server with over 300 nicely arranged projects, it’s hard to imagine now that less than two years ago, TeamCity had no projects hierarchy, introduced in version 8.0 in June, 2013:
projects_hierachy

Version 7.1 came with support of feature branches for Git & Mercurial, which was a huge success with our users. This feature is also used by our internal JetBrains teams so extensively, that it is not clear how we were able to release at all BFBS (before feature branches support):
branches

Build failure conditions, as well as NuGet support were introduced in TeamCity 7.0 in February of 2012! But more astonishing is the fact that this was the time when Agent Pools were introduced for the first time – with over 200 agents and more than 20 agent pools on the TeamCity server here at JetBrains, we see how efficiently our resources are allocated thanks to this feature:
agent_pools

TeamCity 6.5 made all features of the Enterprise Edition available in the free Professional Edition allowing unlimited number of users.

Multiple build steps – an indispensable feature today! – were announced almost 4 years ago, on December 1, 2010 when TeamCity 6.0 was released.
multiple_build_steps

And finally, already 5 years ago, TeamCity 5.0 saw the light with cloud Build Agents on Amazon EC2 and issue trackers integration, which at present are unnoticed, as they are convenient and used every day!
issuepopup

We hope that you enjoyed our short history course. If you come to think of it, it’s pretty amazing actually how much our features have evolved, not to mention the user interface, which is way prettier now!

We would like to thank all of our you, our long-term users and supporters as well as newbies for your dedication to TeamCity! The new version is on its way, and we do hope that it will bring more cool features worth trying and remembering, so don’t miss TeamCity 9.0!

Stay tuned and happy building!

Posted in Blogroll, Design decisions, FYI, Uncategorized | Leave a comment