Automating the landscape: Static virtual machines for developers and testers

We changed the game for our developers and testers within the sustained engineering team at Nintex by creating a Library of Virtual Machines and automating the requesting process, saving the whole team time by getting ready to develop and verify fixes on these different machines.

Once we obtained the developers’ and testers’ requirements, we decided to set time aside to look at how we can automate and alleviate the problem.

Challenges and Requirements

  • Virtual machines take up a lot of resources to host on laptops
  • Previously released product versions take up to one and a half hours to install and can’t avoid losing turnaround time on support tickets for clients
  • How do we configure or enable different types of authentication setups for our product
  • Emails are not working on my environment
  • Website certificates expire annually, I always need to re-apply the base of my virtual machine to fix the certificate then reinstall all previous released builds to get back to my original setup state
  • Nintex K2 licenses expire after three months, which affects each checkpoint of my environment
  • Taking virtual checkpoints takes up a lot storage space, checkpoints are needed so one can easily revert and apply to a previous checkpoint and the environment is ready
  • Microsoft Security patching and cumulative updates and Windows updates (this is a monthly exercise per virtual machine you own) are time-consuming maintenance requirements
  • How do I create my own virtual machine
  • My virtual machine was incorrectly installed
  • The IP address has been incorrectly assigned to my virtual machine

Solution

With all of the above been discussed, the idea was to create six static virtual machines representing each Nintex K2 product. These virtual machines will be hosted on a specific Host Network Server managed by IT. Each static virtual machine would only have one static checkpoint (installed base) which would be managed by the sustained engineering DevOps team. Each virtual machine’s checkpoint would have been preinstalled with the released product and customized with the necessary configuration required. When the time comes to do any kind of maintenance, we would only be required to update one static checkpoint per virtual machine each time.

Creation of a single entry-point (user interface) where users can select to checkout (when wanting to use a specific virtual machine) and check-in (when they are done to make the virtual machine available again). When checking out a virtual machine would mean you are the only one using the machine selected via the user interface.

When checking back in, means you are done on the virtual machine and it would be available for others again. By reviewing the amount of times a specific virtual machine has been checked out, we can see the need to create additional virtual machine clones to accommodate.

Implementation

By using our own built-in software (with Nintex K2 Five) and Microsoft Hyper-V Manager (Hosted on a network server), the following was done:

We created one base virtual machine comprising of following Microsoft products:

  • Windows Server 2016 Standard
  • SharePoint Server 2016
  • Exchange Server 2016

Then installed all the K2 Software prerequisites on the base virtual machine. After that, we configured SharePoint and Exchange to be Nintex K2 ready and also preconfigured Active Directory Foundation Services. Now when we create a Hyper-V differencing disk based on the base virtual machine, no one will need to go through tons of effort to make it happen.

Once the base virtual machine was created, we then created six differencing disks referencing the base image. The base virtual machine disk is around 50 GB in size. Each differencing disk generated would be around five GB each. When we install Nintex K2 products, this will increase the differencing disk size as with Microsoft product and Windows updates.

In Hyper-V Manager, we then created a new virtual machine using minimum memory and CPU needed to run the virtual machine and pointed this virtual machine to a single differencing disk and called this for example (Hosted K2 4.7 R3). We repeated the creation of new virtual machine option five more times and ended up with six virtual machines now hosted.

We now have the following hosted machines on a single network server which has our on-premises Nintex K2 software installed:

  • Hosted Nintex K2 4.7 R3 – DavidG
  • Hosted Nintex K2 Five 5.0 – DavidG
  • Hosted Nintex K2 Five 5.1 R2 – DavidG
  • Hosted Nintex K2 Five 5.2 R2 – DavidG
  • Hosted Nintex K2 Five 5.3 R2 – DavidG
  • Hosted Nintex K2 Five 5.4 R2 – DavidG

We created a new clean base (No SharePoint or Exchange) virtual machine to locally host our released cloud product offering. Then created two preconfigured local cloud Hyper-V templates, these will host our latest released product version which are also hosted on the network server as follows:

  • Nintex K2 Cloud Update 15-Temp1-DavidG
  • Nintex K2 Cloud Update 15-Temp2-DavidG

The reason we appended the name was intended for IT to reach out to our team for network server maintenance required as we were the owner.

On each of the above virtual machines, we then went and installed each Nintex K2 product and preconfigured and registered SharePoint with the Nintex K2 application. Then went ahead and preconfigured K2 Software to be able to use multi authentication against our product sites (disabled by default). After that, we setup the ability for users to right click on the virtual machine desktop to enable forms authentication of Active Directory Federation Services, also included a Start, Stop function in the right click menu to stop and start Microsoft Exchange as this is heavy on resources. On each machine we created a start-up script which will auto-renew the Nintex K2 license key, preventing expired product licenses. We created browser tabs created for ease of use. Once all this was completed, we then created a single checkpoint of each machine and called the checkpoint BASE.

Now for the Nintex K2 side of things. I created a two Nintex K2 SmartObjects, each SmartObject has the following properties:

  • ID
  • VM Name
  • Product
  • Snap (default is BASE)
  • Check Out By
  • Status
  • Check Out Date
  • Progress
  • Email

Once these two SmartObjects have been deployed to the Nintex K2 server, we are now able to generate views and forms based on these SmartObjects.

Then we created a single-view based on the On-Premises virtual machines and another view based on the cloud virtual machines, both views are bound to the SmartObjects List Method. We also added toolbar buttons (Check-Out, Check-In and Refresh).

Then we created records in each SmartObject representing the virtual machine information displayed in Hyper-V Manager. Once that was done, then we created a new form and combined these two views within the form.

As a bonus, we created the additional SmartObjects, one to record the history of the Check-Out’s and the other two to display the virtual machine information (what the base image is comprised of). On the form we add rules behind the Check-Out and Check-In button and a Refresh button.

Then we needed a Nintex K2 workflow to manage the Hyper-V instructions, illustrated below when a virtual machine is checked out:

Automating the landscape: static virtual machines for developers and testers

Illustrated below when a virtual machine is checked back in:

Automating the landscape: static virtual machines for developers and testers

Below is the landing page for users to access:

Automating the landscape: static virtual machines for developers and testers

How it works

When a user navigates to the landing page, the user will select which Nintex K2 product version in the list view provided and click on the Check-Out button. Once the Check-Out option has been clicked, a popup displays informing the user that the virtual machine will be available in around 4 minutes. This is because a Nintex K2 workflow is fired off that event and reverts the virtual machine back to the BASE checkpoint and starts it up. Once started, the Nintex K2 workflow will wait for the IP address to be returned, once the IP address has been obtained, the workflow will send an email to the user with login details to the virtual machine they selected. When a virtual machine has been checked out, no other user can request this virtual machine until the checked out user has checked the virtual machine back in.

When the virtual machine has been checked back in, another Nintex K2 workflow is fired off to switch off that virtual machine to spare resources on the hosted network server and the virtual machine would be available again for Checkout.

 

 

Interested in exploring more engineering posts from our team here at Nintex? Click here to discover more.

 

 

David Gray

David Gray is a Senior Systems Reliability Engineer at Nintex. He is based out of South Africa and works on the Night's Watch team.

Request a live demo
See how you can manage, automate and optimize your business processes today ‐ get a demo from one of our experts.
Why Our Customers Trust Nintex on

Please wait while form loads...

Couldn't load the form.

Please disable your ad blocker or try a different browser. If you continue to experience issues, please contact info@nintex.com