The Cycle Appliance provides a platform that facilitates continuous testing and continuous integration through cloud-based infrastructure running Jenkins in Azure. The main objective of the Cycle Appliance is to make getting started with these technologies quicker and easier. Therefore, the Cycle Appliance automates much of the necessary configuration. While most of the setup is done by the Cycle Appliance, some up-front work does need to be completed by the user in order to get the most out of using what the Cycle Appliance has to offer. This article outlines some prerequisites before deploying and using the Cycle Appliance.
In order to secure the network connection between Azure and the on-premise network, a Virtual Private Network (VPN) is required. Confirm that a VPN device compatible with Azure is configured. As a part of this process, determine the IP address ranges located on the on-premise network.
For more information about compatible VPN devices and device configuration, see the “About VPN Device” in the Azure documentation.
The best use of Jenkins for continuous testing is going to come in large part by employing version control. By linking Jenkins with a repository, test executions can automatically be triggered by changes.
For Jenkins Pipelines, that can either be Git (recommended) or Subversion. Any provider, such as Bitbucket or Github, or internal server hosting these repositories will suffice.
While testing literature typically recommends building a totally fresh instance of the system under test, for many applications that can be extremely difficult. For those that are testing applications that can not be readily re-deployed each test execution, it is recommended to at least have a stand-alone system, or multiple systems if possible, just for the Jenkins Pipeline to test against. This greatly reduces potential tests failing due to multiple tests or users interacting with the same system concurrently.
Similarly, being able to snap-shot and frequently restore the test environment’s databases to a desired state is of vital importance. Complex applications with intricate databases can easily lead to stale data from previous test executions being left over if not cleaned up properly. Regularly restoring the test environment’s databases will help prevent any test failures due to this left over data.