Test Environment

Its pretty trivial really
i've always setup a test or dev or both environments on the same network as the prod jss.
i just use -test or -dev suffixes for the hostnames when settings things up so instead of

myjss.example.com i have myjss-test.example.com or myjss-dev.test.example.com
then its just a matter of setting it up as per normal importing the backup etc etc

that way you can have a prod machine talk to a prod jss and then also have a test machine talk to your test jss all on the same network so its easy to then switch the client to talk to either prod or test jss's

is that the kind of thing your after?

I set up a dev JSS on a VMware Fusion instance on an old iMac I had sitting in inventory. I enrolled an out-of-warranty MacBook Pro into that dev JSS and use it to test policy pushes and configs so I can see end-user experience before I attempt them in production. VMware Fusion makes it really easy to spin up an OS X VM, especially if you have an Install OS X Mavericks.app sitting in your Applications folder.

This has a clue to start you off: https://jamfnation.jamfsoftware.com/article.html?id=136

There is some awesome advice from @tlarkin here: https://jamfnation.jamfsoftware.com/discussion.html?id=11073

And from my first test environment, I wrote these notes to self last month:

* AFTER EVERY DB RESTORE FROM LIVE CHANGE: JSS URL (Global Management -> JSS URL) to jss-test.myschool.org APN Cert (Global Management -> Push Certificates) Delete existing Click New and go through the wizard. Have to create a new APN each time as it has to match the newly created CSR. SMTP 'Sender Display Name' (System Settings -> SMTP Server -> Edit) to include 'TEST' *** IF TOMCAT IS A BRAND NEW INSTALL 'Change the SSL certificate used for HTTPS' and restart Tomcat (System Settings -> Apache Tomcat Settings -> Edit) Be sure the URL has already been changed (above)

Strictly speaking I think you can use the same APN cert but I read a comment that suggested a different one.

chris

Thank you for the responses!

Hi @jfitzpatrick][/url][/url

I hope you are doing well. I just wanted to chime in, because test environments I think are a must have thing, and they need to reflect aspects of your infrastructure and systems. I have been burned a few times because my test environments did not match production 100%. This is how I like to consult customers on this topic. I suggest you create 3 specific instances of your JSS infrastructure and deployment, which would include:

• Dev Environment
• UAT (User Acceptance Testing) Environment)
• Prod (Production)

How I define each instances would be the following:

Dev is your playground. This can be a separate instance, a local VM on your laptop, maybe a Mac Mini on your desk, etc. The idea is that this can be ran in many different ways and this is where you build all your solutions, your proof of concepts, so on and so forth.

UAT is where all your workflow and solution validation happens. You take all your workflows you build in your dev environments. This can involve whatever QA (quality assurance) processes you may have internally. UAT could also involve a small test group of users who love to be bleeding edge. Nothing is promoted to Prod until it has been completely validated as a working workflow and a solution that end users would find acceptable. UAT should always mirror production on an infrastructure and systems level. If your production environment has 4 web apps, a load balancer and several HA Apache proxies, your UAT should as well. Along with the same exact configurations. It needs to parallel production, and this is important so it takes all environmental variables out of the equation.

Production - this is where your solutions are deployed in your live infrastructure hitting production systems and clients.

So ideally, you would build everything in dev, validate it in UAT, and once validated promote it to production. Virtualization is awesome for this. I setup a lot of local VMs on my work computers and use the avahi-daemon for mDNS and do all my testing in that sort of environment. This is also how I try to build out customer environments when I am working on a project or support issue with them. This is what works for me.

Hope this helps,
Tom

@tlarkin thanks for the response, great advice

@tlarkin - How are you able to get by the 'human error" potential/factor between your UAT and PROD environments? Are you somehow able to "export" say, a policy, script or setting, out of your DEV environment and import it into PROD?

I could be wrong, but I don't believe this is something JSS could do. I'm looking for some solid process that could be used to truly use the same code from those type of Test, DEV and/or UAT environments.

Thanks,
Ben

Although not as easy to setup, I would do this with the APIs. You would have a script that would read the data from the test environment and import into the PROD environment.

thanks for all this useful info. i have one question @tlarkin, (and everyone as well), what do you do with your caspershare packages between UAT and production? Do you use the same master folder for both/all instances of JSS?

thanks,
sk

I wouldn't use the same server, but perhaps rsync or Robocopy between production and test JSS (not the other direction, I'd do that manually).

Something else to keep in mind is that if you use DEP or VPP, you'll want to delete those accounts from your Dev environment as well. You can have some odd issues pop up when two servers are managing the service.

good point on the DEP stuff.. i saw elsewhere tha I should create a new APN cert for test environments too.. thanks for all the info!

@skoonin

I think that is totally up to you and your preference and resources you have. When I was testing stuff I did it in a complete separate environment. Once my package and workflow passed all validation and QA testing, I would then upload the package to production and create a policy to deploy it.

I used a Mac Mini as my UAT/dev environment though. It was a tiny environment that had around 10 or so clients enrolled into it at any given time. Mostly for scope testing in regards to smart group membership when deploying policy to OS X devices.

I would suggest that keeping them separate just for the simple fact that it would mitigate accidentally pushing out a test package or test policy.

@benducklow

There are many ways to do this. Manually of course does have the human error which you speak of. Back when I was just a Sys Admin doing pure IT things at my old gig I would manually test it. This was because back then the API did not exist for the bulk of my time as a Casper Admin.

Last JNUC I had quite a few conversations regarding this. I have heard of people using private GitHub accounts to commit, push, and pull policies from one JSS to another via the git binary. This also allows for version control, via GitHub. I do believe Expedia published their workflow using this on their own GitHub account. I believe they posted a link on JAMF Nation about it, let me see if I can find it.

Thanks,
Tom

To those who have setup a test environment, how do you activate your test JSS? Do you simply use the same activation code that you have on your production JSS server, or is there a separate purchase to build a test JSS?

@justinkallas

Send an email to your account manger with the subject line as "Development License Key Request".

How do i get jamf application activation code for test environment.

@venkatjss see reply by @Aziz right above your post.