19 plugins in category «Other Systems Support»

Applitools Eyes

This plugin adds Applitools Eyes test results to your TeamCity build report.
Check out https://github.com/applitools/eyes.teamcity for more information.

Artifactory

Artifactory repository manager integration and enhancements to Maven release process developed by JFrog

AWS CodePipeline

makes a TeamCity build a part of an AWS CodePipeline stage

Azure Active Directory

TeamCity user authentication via the login to Azure AD

Black Duck Hub

This plugin provides ability to run a scan using the Black Duck Hub CLI on build input and/or output. You can scan multiple targets, fail builds based on Hub policies, and display Hub reports for a particular Build.

BrowserStack

Use the BrowserStack TeamCity plugin to easily integrate your TeamCity setup with BrowserStack. Use this plugin you can:

  1. Manage your BrowserStack credentials globally or per build job
  2. Set up and teardown BrowserStack Local for testing internal, dev or staging environments
  3. Embed BrowserStack Automate reports in your TeamCity job results

Cadence vManager

a build runner to execute remote API calls to Cadence vManager

Crowd Authentication

a plugin for TeamCity to allow user login through Atlassian Crowd. ( blog post, announcement)

Graphite Integration

sends various build, code and test metrics (including FxCop and OpenCover) to Graphite/StatsD.

JMeter

integrate with JMeter for performance testing within builds and displaying trends.

Leiningen

Clojure Leiningen plugin for on-the-fly stages, tests and artifacts reporting to TeamCity

Nouvola DiveCloud

Nouvola Plugin

Cloud-based, scalable load testing and performance testing for your web, mobile and API, using the power of Nouvola.

Nouvola is the performance testing and analytics solution created by developers, for developers. Enjoy script-free performance testing, real-world ready scenarios and in-depth performance analytics across any load, any device, any geo.

OctopusPuppet

*What* Provides a way to visualize, orchestrate differential deployments in Octopus. *Branch Deployment* Will deploy all components that have SemVer pre-release that matches given branch. The latest component will be selected. If the target environment already has the exact component it will be skipped. All components that do not have a matching SemVer pre-release will then match no SemVer pre-release (i.e. master). The latest component will be selected. If the target environment already has the component it will be skipped. This is often used for testing a feature branch. Features can span multiple repositories which means multiple components. *Mirror Environment Deployment* Will deploy all components from source environment to target environment. The exact component is matched. If the target environment already has the exact component it will be skipped. This is often used for promoting a product from one environment to another or when developers want to debug a product on their own machines. *Redeployment* Will redeploy all components. The exact component is matched. This is often used for redeploying when settings/feature toggles have changed. Why When running micro-services architecture one of the downsides is that there is plenty of stuff to deploy. To reduce this tax you need to ensure as much as possible is automated. Octopus goes a long way to making a great experience, but there are a few short comings. Deployment Taxes: It is often difficult to see how components are dependent on each other. The ideal situation is a graphical graph which shows component deployment dependencies. Having one giant octopus deployment project is not feasible either. Often we don't want to deploy everything as this takes ages. The ideal situation is a differential deployment. It will only deploy what has not already been deployed. There appears to be no way of calling other deployments from a deployment in Octopus. This is due to Octopus will block the deployment. So you can't call the Octopus API and wait until the deployment is finished as Octopus will only start running the task once the wait is finished. The ideal situation is a way to call deployments from deployments or have something that can orchestrate this.

Rally

publishes TeamCity build events to Rally.

SauceLabs

integrates with Sauce Labs (cloud-based browser and mobile testing platform) ( sources)

SonarQube

a build runner to run Sonar code analysis and publish it to Sonar

Upsource links

adds links to JetBrains Upsource reviews to changes displayed in TeamCity

VersionOne

download, sources - by VersionOne

WhiteSource

integration with WhiteSource open-source licenses management solution