Test using virtual machines

[Denis Troller]

We are using GO-CD to build and test our product under Windows. The product is a desktop application.

We have a pipeline that builds the product and we use virtual machines (under HyperV) to test it in controlled environments. Each VM hosts a GOCD agent to carry out the installation and testing of our product.

The system needs to reset the VMs by applying a snapshot before actual deployment and testing can occur. 

It is easy to restore the VMs using powershell.

The big-picture pipelines are:

- Build

- Hardware-Tests (on a real machine with hardware attached): Copy files, Test Application

- Software-Tests (on a VM): Restore VM, install Application, test

- Customer-Specific tests (on a VM): Restore VM, install Application, test

This set of pipelines is replicated for each maintenance branch of the product (trunk, v1.0.*, v1.1.*... v2.0.*)

Ideally I would like to be able to have any number of VMs available for software and customer tests to allow concurrent builds of different versions of the product.

My problem is in modelling this in GOCD since I do no want two pipelines to restore the same VM. GOCD can choose a VM agent to cary out the testing, but the agent cannot restore its own VM (since it will then disappear and be reset, leading to a pipeline failure).

Any idea on how to deal with such an environment ? Or am I doing this wrong ? Has anyone implemented something like this before ?

[Ketan Padegaonkar]

There are 2 possible ways (that I can think of):

1. Use a set of scripts that runs on an agent. These scripts will connects to a VM provider (vmware, virtualbox, ...) to spin up VMs. Then connect to the created VM to install, configure and test whatever you need to test.
   
2. Write an elastic agent plugin for your VM provider (or use an existing one). Elastic agents can bring up agents in response to build workloads.

I'd think option 1 is probably what you may want to start with, before diving into option 2.

- Ketan

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/6c3a3cd3-cfb6-469f-ab4a-2ed35b011e1d%40googlegroups.com.

[Denis Troller]

Thanks, I get that, although for now in my case the VMs are already provisionned.

My problem is, given two identical pipelines (same description, maybe based on the same template) for testing that could potentially run at the same time, how do I make it so that the piepline chooses one VM to reset and then runs the testing jobs on this particular agent ?

To unsubscribe from this group and stop receiving emails from it, send an email to go...@googlegroups.com.

[Ketan Padegaonkar]

On Thu, Aug 1, 2019 at 6:26 AM Denis Troller <denis....@gmail.com> wrote:

how do I make it so that the piepline chooses one VM to reset and then runs the testing jobs on this particular agent ?

A cheap way might be to write a file (or some metadata) to a VM if it has been acquired by a job, if another job tries to acquire it, it must back off (or try another VM). A really fancy way would be to have another DB that records which VMs are available and which have been acquired/released after a build.