Building test environment

[corbinmharris]

I am planning on setting up a test/beta environment to prepare for the next version of Casper and OS X 10.0, along with patchoo. The MacMini running OS X server and test Macs will be on their own VLAN, so it is just a matter of getting the JSS configured correctly on the Mac mini.

I have an external drive that has a Carbon Copy Cloner bootable backup every night. Is it a good idea to turn off MySQL on the production OS X Server and do an updated clone and then use that to image the MacMini or am I better off doing a fresh MySQL install?

Thanks!

Corbin

[gskibum]

I'm no expert on scripting, but Carbon Copy Cloner can run shell scripts to automate the process of freezing databases like MySQL. Check out his support page.
http://help.bombich.com

[tlarkin · Accepted solution]

Hi @corbin3ci

I saw your post here and though I might chime in a bit. When you are building test environments, how you build it varies based on what you are accomplishing. If you are trying to test out infrastructure scaling, sure a database dump from production would be ideal. That way you are dealing with similar amounts of data that production has. However, if you are just validating workflows, testing new software betas, and third party products with Casper, you don't necessarily need to use your production database.

I typically recommend 3 environment types for IT to use with any product that is currently in production (this philosophy can be applied to all things, including the Casper Suite). Each type has a specific function. I recommend something along the lines of this:

1 - Dev envirnoment - this can be anything from local VMs, to a Mac Mini, or whatever you want to use to test software with. Dev can be the latest build, beta builds, proof of concept software you want to also deploy in your environment, and dev is non crucial to anything at all. So, it can be deleted, nuked from orbit, it can crash and be unstable, etc.

2 - Test/UAT - UAT is a term for User Acceptance Testing, and this environment should parallel production as much as possible. This is where you validate and QA all your workflows, software installs, etc. Having it parallel production gives you a better idea of how this would work in production. This environment should always be the exact same infrastructure and versions of production.

3 - Production - this is where everything is live and hits the end users

You also will need to regenerate Tomcat SSL certs in the web app if you are taking a back up of production to put in your UAT environment. I would also recommend using a different APNS certificate for Apple Push Notifications as well. You don't want a test/dev environment to send commands to APNS with the same certificate as production.

So, in your case if you are testing out beta software, and wanting to validate workflows with Patchoo, I would recommend just building a dev environment separately from your production environment. These are things that you will need to test and validate before even doing a pilot, so in that scenario you may run into a situation where you want to nuke the environment from orbit so to speak, and start fresh and rebuild.

If you want to use production data for your testing, you can use the database utility JAMF provides with the product. Then just import it with that same tool on a different system. Just know you will have to regenerate the Tomcat SSL certs for the new hostname, and will need to delete out the production MDM certificate for APNS and get a new one for your test environment.

I hope this helps,

Tom

[corbinmharris]

Hi Tom, thanks for the additional information.

Corbin

[cdenesha]

Tom that is extremely helpful, thanks.

[tkimpton]

Just want to add if you work in a global organisation its a good idea to have a global dev server so that engineers in different time zones can collaborate, innovate and provide essential dev troubleshooting effectively :)