TeamCity Plugin Contest 2019: And the Winners Are…

The Contest is over and we want to say a huge Thank You to all the participants for making it a resounding success!

For the past couple of weeks, our judges and members of the TeamCity team have been hard at work trying out, testing, and rating plugins submitted to the Contest. Every submission was judged against four main criteria: usefulness, creativity, completeness, and code quality.

The finalists were really close, which made our judges’ task that much more challenging. After a lot of deliberation and discussion, the list of winners was determined at last:

First prize

Plugin: Deployment Dashboard
Author: Kieron Wilkinson
Award: $3,000 Amazon gift certificate

Judges’ comments: This entry implemented a creative idea with a delightful UI. There is definitely a demand for deployment reporting options in TeamCity.

Second prize

Plugin: SSH Tunnel
Author: Björn Kautler
Award: $2,000 Amazon gift certificate

Judges’ Comments: This entry offers an effective solution to an existing problem and provides complete functionality.

Third prize

Plugin: Portable artifact link generator
Author: Jon Philpot
Award: $1,000 Amazon gift certificate

Judges’ Comments: This is an elegant solution to a real-life use case. (Kudos for the GIF in the documentation!)

TeamCity Team Special Prize

Plugin: Personal Build Toggle
Author: Jon Philpot
Award: Trip to a JetBrains office

Our team’s comments: This plugin perfectly balances implementation and value, and exhibits a straightforward approach to configuration.

The People’s Choice Award

This award was based on the community voting on the Plugin Contest website. As there was a tie between two plugins, we decided to give the award to both.

Plugin: Deployment Dashboard
Author: Kieron Wilkinson

Plugin: Usage Search
Author: Rod MacKenzie

Award: 1-year subscription to the All Products Pack and 1 TeamCity Build Agent license

Congratulations to the winners! We will be contacting you shortly after this announcement to deliver your prizes.

We are grateful to everyone who participated for all the efforts you have put into developing and finalizing your plugins! Thanks to you, the following 15 plugins are now publicly available in our Plugin Repository:

Congratulations, and happy building!

Posted in Contest, Plugin development | Leave a comment

Kickstart continuous testing using TeamCity’s integration with LambdaTest

This guest post is brought to you by Harshit Paul, a Content Specialist at LambdaTest.

TeamCity now offers integration with LambdaTest, a cloud-based cross-browser testing tool offering automation with Selenium Grid. LambdaTest offers a library of 2000+ real browsers for both mobile and desktop devices. Serving more than 60,000 users every year, LambdaTest is one of the fastest-growing cross-browser testing clouds.

lambdatest.001

Why are developers & testers fond of LambdaTest?

  • Selenium API – LambdaTest offers an Open API for their Selenium Grid, empowering their users to extract test reports of the script executed on their platform. You can extract these reports from LambdaTest’s cloud to your preferred storage facility, even without logging in.
  • Intuitive Test Logs – Offering a neat & organized automation dashboard, LambdaTest provides great visibility over your automated Selenium test scripts. You can find details such as timestamps, test status, network logs, command logs, Selenium logs, metadata, and more.
  • Native Built-in Dev Tools – LambdaTest offers developer tools for every possible browser included in their platform.
  • Parallel Testing – LambdaTest offers an easy-to-scale Selenium Grid where you can perform multiple Selenium test scripts, simultaneously.
  • Test Locally Hosted Web Pages – You can ensure how well your website will look after every code change, by performing cross-browser testing of locally hosted web pages or web applications using an SSH tunnel termed as Lambda Tunnel.
  • Numerous Third-Party Integrations – You will find various third-party integrations with project management tools, instant messaging platforms, and continuous integration & continuous deployment tools such as TeamCity.
  • One-Click Bug Logging – Highlighting bugs and sharing them with colleagues are often a tedious task. Well, not if you are using LambdaTest: it offers a built-in image editor which helps you highlight a bug and share it with your colleagues or on the project management tool’s dashboard in one click, thanks to the LambdaTest integrations.
  • 24/7 Customer Chat Support – If you ever come across any issue related to platform usage, or any suggestions regarding the product, you can simply give the support team a shout through the chatbot and expect a response in under a minute.

How can TeamCity integration with LambdaTest help your continuous testing workflow?

TeamCity’s integration with LambdaTest will empower you with continuous integration, continuous deployment, and continuous testing.

Test your code commits before migrating them to the Production – As you commit changes to your project, you can have them tested over different browsers by performing cross-browser testing with LambdaTest through their Selenium Grid & SSH(Secure Shell) tunnel. The SSH tunnel establishes a secure connection between your system and LambdaTest cloud servers, allowing you to host your local web pages on their virtual machines. That way, you can see how your code changes will affect your website’s UI when accessed through various browsers.

Faster automated cross-browser testing & faster CI CD pipeline – The primary purpose of automation testing is to cut short the time & effort of your routine test cycles. However, the sequential execution of test scripts can be very time-consuming. Parallel testing with LambdaTest Selenium Grid will help you overcome the drawback of sequential execution as you will be running multiple Selenium tests simultaneously. By using TeamCity along with LambdaTest Selenium Grid, you can have a faster pipeline and rapid test validation for browser compatibility of your latest release before making it live.

Test & push hassle-free, from anytime, anywhere using cloud – LambdaTest & TeamCity both offer an entire CI CD & test solution on the cloud. That means you can get rid of the hassle that often comes with setting up the infrastructure and maintaining it. LambdaTest gives you access to real mobile and desktop browsers. You get a variety of desktop devices including operating systems for both Windows and Mac. For mobile testing, you can select from Android and iOS devices. You could also test on tablets and iPads to ensure how responsive your website is turning out to be after the last code commit.

Open API to help you customize your user experience – Both LambdaTest & TeamCity offer Open APIs. TeamCity’s Open API allows you to create your own custom plugin if none of the hundreds of plugin offered is suitable for your project. LambdaTest offers an open Selenium API to help you extract Selenium test reports from LambdaTest to your preferred storage without logging in to the platform.

Reliable scalable architecture and licensing – Both LambdaTest and TeamCity provide a secure and robust platform which you can scale according to your project requirements. You can start using the product with free licensing and scale later as your project demands grow. With TeamCity, you can expand server capacities as you like; with LambdaTest, you can increase the number of concurrent sessions to help run more test cases in parallel.

All you need to do is declare the Selenium script while configuring a build on your TeamCity instance, along with environment variables specific to LambdaTest authorization, and you are good to go.

Running your first Selenium script on LambdaTest from your TeamCity project

Step 1: Create a new project and add a new VCS routing to Git repository. Here is a sample git repository to help you run your first Selenium script using Protractor.

Step 2: Create build configurations and go to the Build Step page to enter the below command as your script for running a single test script.
Powershell -Command “protractor conf\single.conf.js”

Similarly, if you wish to run multiple tests in parallel, then run the below script:
Powershell -Command “protractor conf\parallel.conf.js”

Step 3: Save your build step and provide the LambdaTest username and access key as the environment variable for authenticating your LambdaTest account with the TeamCity instance.

Step 4: Run your project from the Project dashboard.

It’s time to build the future

Together with LambdaTest, we’re committed to simplifying your continuous testing workflows so that you can focus on making innovative products and solve real-world problems, rather than merely testing older ideas.

What do you think of this integration? Let us know in the comments section.

Posted in Guest post | Tagged , | Leave a comment

TeamCity Plugin Contest: submissions are closed, you can now vote for the plugins

The TeamCity Plugin Contest has entered its final chapter as we yesterday closed the door to any more plugin submissions. We would like to thank every one of the participants who spread the word, joined the contest, and spent their valuable time developing new plugins. Thank you all – we really appreciate your efforts!

TeamCity Plugin Contest 2019_e-mail-03

Of the 89 developers registered for the contest, 15 submitted valid plugins, each of whom have received a 1-year subscription to a JetBrains IDE of their choice. Congratulations!

Submissions for the contest are now closed, and so begins the judging and voting for the best plugin. You can review all the submitted plugins and vote for the ones you like the best. The author of the most voted plugin will receive the People’s Choice Award.

Vote for plugins

We will announce the five winners on July 17.

So fingers-crossed, be patient, and don’t forget to pick your favorite plugins. Follow our blog or twitter for the winners’ announcement.

Thanks again and happy building!

Posted in Contest, Plugin development | Tagged , | Leave a comment

TeamCity 2019.1.1 is here

TeamCity 2019.1.1 is available!

This release fixes over 100 issues including several performance problems. Notably, these fixes have affected:

  • New experimental UI
  • Multinode configuration
  • Kotlin DSL

We have also addressed the recent changes in the Bitbucket REST API and improved TeamCity Bitbucket cloud connections accordingly.

You can find the full list of fixed issues in our Release Notes.

We recommend upgrading to version 2019.1.1 to benefit from all the latest improvements.
This new version uses the same data format as 2019.1 release which makes it easy to upgrade/downgrade within these builds.

You can select any of these upgrade options:

Remember to check our Upgrade Notes to make sure your upgrade to TeamCity 2019.1.1 goes smoothly.

You can leave feedback in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Leave a comment

New topics in Plugin SDK documentation

The TeamCity Plugin Contest is ongoing and there is still enough time to write some cool plugins!

If you’re already participating, we’ve just added a couple of new articles in our Plugin SDK documentation to make your life a little easier:

  • The first one describes different approaches to how the plugin state and plugin settings can be stored in TeamCity. This is a very common task but unfortunately was not described at all up until this point.
  • The second one describes how build features can be implemented. Sometimes you just want to affect how a build behaves, and this behavior change can’t be represented as a step, because steps follow a strict order. Build features can come handy in this case. Examples of build features in TeamCity are XML report processing, Build files cleaner, and File content replacer.

We plan to continue adding new topics to our Plugin SDK documentation. We also welcome your ideas on what could be described better or what you think is missing in our documentation.

By the way, the TeamCity Plugin SDK documentation is now located on GitHub: https://github.com/JetBrains/teamcity-sdk-docs. If you notice a mistake or anything incorrect there, feel free to create a pull request or submit a bug report.

Posted in Plugin development | Leave a comment

14 Cool TeamCity Plugins You Can Start Using Right Now

As you may know, the TeamCity Plugin Contest 2019 is in full swing and its participants are coming up with brilliant new creative solutions as we speak.

While TeamCity provides a lot of functionality out of the box and bundles a number of plugins in its distribution package, there are still use cases where you might need something extra. In this blog post, we are going to list 14 cool plugins that add new features or integrate with external tools. The plugins are not bundled with TeamCity in the distribution package but can be easily installed from the JetBrains plugins repository.

First, let’s take a look at the plugins that add new functionality to TeamCity for a very specific task in your build process. It could be a plugin that adds in integration with a build tool, provides a specific build step or a build feature, a UI extension, and so on.

Agents priority is a very nice plugin developed as part of our previous TeamCity Plugin Contest. The plugin lets you order TeamCity build agents by different criteria. Whenever a build starts, an available agent with the highest priority will be used.

tc-agents-priority

AutoProperties provides a build feature that can set parameters based on whether the build was triggered by a user. It can also set different parameters depending on those that exist already. The plugin will run before any build steps are executed, so the updated parameters will be immediately available.

The Gradle Build Cache plugin applies the Gradle Hazelcast settings plugin to enable remote build caching, and starts a Hazelcast node on the TeamCity server. This should make your Gradle builds run faster – very useful!

REST runner is also one of the plugins developed during the previous TeamCity Plugin Contest. It adds a build step that allows you to execute an HTTP request to an external service and handle the response using a Groovy script.

TeamCity OAuth is a lightweight alternative to the functionality provided by JetBrains Hub, enabling GitHub or generic oAuth2 authentication for TeamCity.

The SSH Tunnel plugin adds a build feature that allows SSH tunnels to be opened with port and socket forwarding. After adding the build feature to a build configuration, the plugin opens the configured SSH tunnels before the build starts, and any step in the build can use the established forwards.

Now for something different… Achievements is a fun feature that grants TeamCity users various badges based on their activities. The badges are displayed at the top of the screen, next to the user’s name. Here are a few examples:

  • Novelist – Granted for extra long commit descriptions.
  • Debugger – Granted for a series of commits mentioning fixed bugs.
  • Big Brother – Granted for assigning investigations to several different persons.
  • Boy Scout – Granted for assigning several investigations for a test or problem to himself.
  • … there’s more!

tc-achievemnts

Use the Achievements plugin to add some fun in your CI experience! 😉

The Invitations plugin lets you invite users to create or join TeamCity projects. We use this plugin at the test hosted TeamCity instance to simplify collaboration for users.

Kubernetes support is a plugin that allows TeamCity cloud agents to run in a Kubernetes cluster and provides a ‘Helm’ build step.

The Rust plugin for TeamCity enables you to build Rust programs with Cargo. The plugin detects the Cargo.toml configuration file once you add a VCS root to the Build Configuration, and suggests the corresponding build steps.

Bazel plugin adds a corresponding build step and integrates with the core functionality of TeamCity. This includes auto-discovery of build steps, Bazel tool detection on build agents, and cleanup of Bazel workspace caches. It also adds a build feature for Bazel’s remote cache in order to speed up your builds.

You can find many more interesting TeamCity plugins in JetBrains Plugins Repository. What’s more, you can become a plugin author – and the ongoing TeamCity Plugin Contest is a great opportunity to try your hand at this! So if you feel you’re up to it, hurry and apply!

Now, let’s look at another category of plugins that provide integration with external services to enhance your CI/CD pipeline.

A proper CI/CD pipeline today poses requirements that go beyond the traditional build process. This includes steps for security scanning, managing binaries, running deployment tasks, managing environments, working with the reports produced by the build server, and much more. For many of these activities, there are services or tools that integrate nicely with TeamCity. Here are a few interesting tools that will help you build a sophisticated CI/CD pipeline in collaboration with TeamCity.

The Snyk plugin adds the ability to test your code dependencies for vulnerabilities against the Snyk database. When you use the Snyk plugin in TeamCity, the build process makes sure that it is in line with the Snyk org’s rules. The build will fail if the security scan detects that the code is vulnerable beyond what the policy allows.

As a result of a build process in TeamCity, we often produce binary artifacts that can stay in the build server. However, there are products tailored for working with binaries which are definitely worth using for managing your artifacts. Artifactory is a tool designed to work with binaries, and the Artifactory plugin for TeamCity makes the integration possible.

Beyond managing the efficient deployment of your artifacts to Artifactory, the plugin lets you capture information about artifacts deployed, dependencies resolved, environment data associated with the TeamCity build runs and more, that effectively provides full traceability for your builds. (link)

Not only do we produce and manage the binaries in the CI/CD process, but we also need to somehow deliver the artifacts into the environment to serve the business. Octopus Deploy is a convenient tool for delivering software packages to the servers.

The Octopus Deploy plugin for TeamCity integrates with the Octopus Deploy server in order to deliver NuGet, zip, tar, gzip, tar, bzip2, jar, war, ear and rar packages for deployment. TeamCity builds the packages and runs tests, and then Octopus Deploy takes those packages and pushes them through the development, test, and production environments.

OD

We recently hosted a webinar about using Octopus Deploy with TeamCity and the recording is available for you to watch.

As you can see, there are plenty of interesting plugins for TeamCity tailored to many specific use cases. I would venture a guess that you, too, may have a particular use case that stands to be implemented via a plugin. Fancy having a go at it? There’s still time left, so apply for the TeamCity Plugin Contest, submit your solution, and win the day!

Posted in Blogroll, Contest | Tagged | Leave a comment

TeamCity 2019.1: New UI, GitLab Integration, Support for Go, Token-Based Authentication, AWS Spot Fleet Requests

Please welcome TeamCity 2019.1—the first major release of this year! TeamCity 2019.1 provides a redesigned UI, native GitLab integration, and support for GitLab and Bitbucket server pull requests. Also included are token-based authentication, detection and reporting of Go tests, faster build agent upgrades, and AWS Spot Fleet requests.

800x418_Twitter_card_release @2x

Here are the key new features of the release.

New look, new feel, fewer clicks

TeamCity UI is getting a major overhaul, and here’s a first taste of what you’re going to get in this version.

Not only have we improved the look, but we’ve also updated the underlying technology stack so now the UI works as a single-page application, which means you can access parts of it faster and all the changes appear instantly. See the full TeamCity UI roadmap to stay up to date with all the planned changes.

In 2019.1, we are targeting the pages related to working with projects and build configurations.

screen1@2x

The new sidebar provides easy access to your builds and projects. The quick search lets you navigate to other build-related pages.
The project overview has been completely reworked and now provides a dashboard-style view over your build configurations.
The reworked Branches tab on the build configuration overview now displays your default branch, increasing the visibility of the most important data.

branches@2x

Full GitLab support out of the box

Using GitLab? TeamCity 2019.1 adds full support for GitLab. You can now set up a GitLab connection and create projects in TeamCity with one click, by simply picking a GitLab project from the list.

We’ve also added support for GitLab merge requests, so you can now set TeamCity up to automatically run the build on each merge request and then automerge it if the build is successful.

Go the distance

The Go language is now supported natively by TeamCity. Add your Go projects and TeamCity will detect and report Go tests, providing rich insights into the test status, its history across the builds and its duration, and will mark unstable tests as flaky.

Token-based authentication

In addition to basic HTTP authentication, TeamCity now supports authentication based on permanent access tokens. With tokens, you don’t need to expose a user login and password in scripts. Tokens are also useful for REST API authentication.
token-based-authentication

Snapshot dependencies without sources synchronization

You can now set up TeamCity to trigger snapshot dependencies so that it does not synchronize the revisions of code. This is handy when running deployments and lets you promote one of the older builds in the chain using the latest deployment configuration.

AWS Spot Fleet requests

With this more flexible way of creating Spot Instances, you now have more granular control over your Spot Fleet. TeamCity 2019.1 lets you submit and edit the spot fleet configuration file and specify the strategy, set the target capacity, and add tags to your instances. It is a more advanced and cost-effective way of running your builds on AWS.

aws-spot-fleet

Processing build lifecycle on a secondary node

The secondary node now has an additional responsibility: processing the build lifecycle. If you turn it on, the secondary node will handle the build-related tasks, such as running and finishing builds, uploading artifacts, and failure conditions processing. This change expands the already broad list of tasks that you can offload from your main server onto a secondary one: collecting changes from agents, serving as a read-only backup node, and now, processing the build lifecycle.

secondary-node

On-demand tools loading

Tools will now only be loaded onto agents on demand. The necessary tools will be loaded only when the first build requiring them appears. This significantly improves the build agent upgrade times and saves you network traffic.

There is more to this release! See the detailed description of these and other features in the What’s new section in our documentation.

Download TeamCity 2019.1

Please check through the upgrade notes before you install the new version, and do not hesitate to report any issues in our tracker or ask questions in the forum.

Posted in Features, Release | Tagged , | 8 Comments

TeamCity 2019.1 RC has arrived

The release candidate for TeamCity 2019.1 is here with some new exciting features:

  • Using snapshot dependencies without synchronizing revisions
  • Support of BitBucket pull requests
  • GitLab connections
  • Faster agents upgrade
  • Delayed auto-assignment of investigations for flaky tests
  • Separate Maven artifact repository for all builds on an agent
  • Branch filter for version control settings of a build configuration

We have also optimized the TeamCity performance to speed up the startup of main and secondary servers.

Read more about all these changes in our release notes.

This RC build fixes over 100 issues listed in our issue report.

To download TeamCity 2019.1 RC, use the automatic upgrade feature or download the latest build and install it as usual. This build is an interim release so we recommend you to experiment with it on a trial server.

The TeamCity RC builds come without the EAP license but the license for the 2019.1 EAP 3 release is valid for this RC.

We are always glad to receive your feedback in our forum or tracker.

The new TeamCity version is on its way!

Happy building!

Posted in EAP, Features, Release | Leave a comment

Webinar Recording: Turbocharging TeamCity with Octopus Deploy

The recording of our May 14 webinar, Turbocharging TeamCity with Octopus Deploy, is available on the JetBrains YouTube channel.

In this webinar, Derek Campbell showcases how to integrate TeamCity and Octopus Deploy. He starts off with building a solution in TeamCity and takes you through deploying it to Development, Test, and finally to Production environments.

DerekDerek Campbell has worked across the world in London, Melbourne, Singapore and now from home in Glasgow, Scotland, for Octopus Deploy as a CI/CD Architect in the Customer Success team. Derek works with and helps Octopus Deploy’s biggest clients like ASOS, AON and L’Oreal with their CI/CD pipeline and helps enable their success with Octopus Deploy.
Posted in Webinar | Tagged | Leave a comment

Configuration as Code, Part 6: Testing Configuration Scripts

In this blog post, we are going to look at how to test TeamCity configuration scripts.

  1. Getting started with Kotlin DSL
  2. Working with configuration scripts
  3. Creating build configurations dynamically
  4. Extending Kotlin DSL
  5. Using libraries
  6. Testing configuration scripts

Given that the script is implemented with Kotlin, we can simply add a dependency to a testing framework of our choice, set a few parameters and start writing tests for different aspects of our builds.

In our case, we’re going to use JUnit. For this, we need to add the JUnit dependency to the pom.xml file

We also need to define the test directory.

In this example, we have redefined the source directory as well, so it corresponds with the following directory layout.

Once we have this in place, we can write unit tests as we would in any other Kotlin or Java project, accessing the different components of our project, build types, etc.

However, before we can start writing any code we need to make a few adjustments to the script. The reason is that our code for the configuration resides in settings.kts file. The objects that we declared in the kts file are not visible in the other files. Hence, to make these objects visible, we have to extract them into a file (or multiple files) with a kt file extension.

First, instead of declaring the project definition as a block of code in the settings.kts file, we can extract it into an object:

The SpringPetclinic object then refers to the build types, VCS roots, etc.

Next, to make this new object visible to the test code, we need to move this declaration into a file with a kt extension:

kotlin-dsl-test-code-in-files

settings.kts now serves as an entry point for the configuration where the project { } function is called. Everything else can be declared in the other *.kt files and referred to from the main script.

After the adjustments, we can add some tests. For instance, we could validate if all the build types start with a clean checkout:

Configuration checks as part of the CI pipeline

Running the tests locally is just one part of the story. Wouldn’t it be nice to run validation before the build starts?

When we make changes to the Kotlin configuration and check it into the source control, TeamCity synchronizes the changes and it will report any errors it encounters. The ability to now add tests allows us to add another extra layer of checks to make sure that our build script doesn’t contain any scripting errors and that certain things are validated such as the correct VCS checkout, as we’ve seen above, and the appropriate number of build steps are being defined, etc.

We can define a build configuration in TeamCity that will execute the tests for our Kotlin scripts prior to the actual build. Since it is a Maven project, we can apply Maven build step – we just need to specify the correct path to pom.xml, i.e. .teamcity/pom.xml.

kotlin-dsl-code-in-ci-pipeline

The successful run of the new build configuration is a prerequisite for the rest of the build chain. Meaning, if there are any JUnit test failures, then the rest of the chain will not be able to start.

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