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). with which we have tested the connection between the TeamCity server and the build agent.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.on which a TeamCity build agent is installed and configured.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. Tip: When you plan on testing this plugin for. on which all build prerequisites are installed (e.g.
#TEAMCITY BUILD AGENT WINDOWS#
In short, we need to create a Windows or Linux virtual machine: We’ll need to create a virtual machine (image) on which our builds will run. Preparing a Virtual Machine (Image) with TeamCity Agent Once that’s done, we can get started with creating a virtual machine or virtual machine image for our build farm.
Next, start the TeamCity server again and verify the plugin was loaded correctly from the Administration | Plugins List page.
#TEAMCITY BUILD AGENT ARCHIVE#
Shutdown the TeamCity server, download the latest version of the plugin from our build server and copy the downloaded zip archive to the /plugins directory. It is compatible with TeamCity 8.1 and the EAP of TeamCity 9. The TeamCity Azure plugin is not bundled and therefore has to be installed on our TeamCity server. Installing the TeamCity Azure pluginįirst things first, of course. Let’s have a look at how we can get started with a Windows or Linux build agent farm on Microsoft’s cloud platform. TeamCity ensures that the configured maximum number of instances is never exceeded. 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. Not to worry! TeamCity supports scaling out builds to Amazon EC2, and starting today, also Microsoft Azure!įor each queued build, TeamCity first tries to start it on one of the regular, non-cloud agents. One minute we need only one agent to be running, the next minute we need 50.
All comments and thoughts are of course always welcome.In a large TeamCity setup with many projects, it’s often very difficult to predict the load on build agents, for example during releases. Hopefully this little trick will save some of you from many hours spent guessing and waiting for builds to go through only to see them fail again. Simple console apps, custom ones, browsers and (for our aforementioned problem) acceptance tests will all happen before your eyes! We were able to see our automated UI tests happening on the screen and finally identified the problem to be in the configuration of the app for that acceptance testing environment. The command is dead simple (here on a Windows host): \BuildAgent\bin\agent.bat startĪnd there you go! Now the build agent process runs under your account so every process spawned by the agent will appear on your screen in real time. Stop the TeamCity (or equivalent) build agent service and start it manually through a console (usually needs admin privileges). Here’s a small piece of (obvious) wisdom to get around this problem: TeamCity agent is of course running as a service which provides no visibility on the output other than what’s on the build log. But we will inevitably come across cases where it’s not enough. Normally the build log should have enough information to help us identify the problem. “Frustration” is a mild and kid-friendly way to express our feelings at the time and we’ll leave it at that :) Of course running the tests locally on our development machines worked like a charm! Only on the build agent was all red hell breaking loose. The WebDriver was timing out, the screenshots did not show anything helpful and no logs were able to give us any hints as to what was happening. Ever been in the situation where you’re using a CI server (like TeamCity in our case) and the build step is failing, you have no idea why and the build log doesn’t help either? One such case that we came upon was with the acceptance tests.
0 kommentar(er)
