3

We are currently developing a Sitecore package and we have a few automated functional/integration tests as part of this project.

Ideally, every time a developer pushes its code to the trunk our CI/CD pipeline (Jenkins in our case) would identify this event and spawn a new machine to run the automated tests.

The script running on Jenkins is currently able to install a new Sitecore 9.x using SIF, which is awesome. After that, all it has to do is install our package via command-line and then run the automated tests.

Since we can have as many tests running in parallel as our team want (or as many as our team can merge its stuff) these Sitecore instances must be created on demand, that's the reason we are spawning a new machine for every scenario.

I was wondering what would be the best approach when it comes to Sitecore 8x since we can't use SIF.

Did someone else face a similar situation in the past and/or have an idea?

Any help is appreciated.

Thanks in advance.

Improve this question

3 Answers 3

Reset to default
3

The way I manage to solve a very similar problem in the past with Sitecore 8.x was to have "seed" installations of Sitecore (8.0, 8.1, 8.2, etc.). Each installation would contain:

  • Sitecore Base installation
  • Any modules required installed
  • External dependencies
  • Everything vanilla configuration

Option 1: The seed can be a collection of Zip files with databases and website folder, that you just copy and unzip to the right folder. After that you run some PowerShell scripts to fix folder permissions and restore databases. I'm assuming here a pool of shared resources (MongoDB, SQL Server, etc.) available to all instance, with each one of them pointing to specific collections on MongoDB, Databases on SQL Server, etc.

Option 2: If you want to go one step further, you can have VMs with Snapshot points where you can always restore to the "seed" state, and deploy again. On this case, you just need to make sure all of your VMs are synced, if you have more than one on your test environment. That's the choice that I went once I had proved the approach above mentioned with Zip files. Just be careful if you want to spin up new VMs based on the seed, you may want to check WinPE to create a seed of the VMs that you can replicate as much as you want.

Improve this answer
1

For the records, that's the way we are dealing with this challenge currently.

We took the easiest approach possible even if it is not the most elegant.

We just created this Windows Machine image which contains a bunch of Sitecore instances already installed, one for each Sitecore version we want to run our automated tests (7.2 until 9.1). The instance names are following an internal convention by the way.

Then, all Jenkins has to do is spawn a new machine using this image.

On that way, the automation script can blindly access the wanted Sitecore version (since it can predict its name) and do whatever it wants with it.

Improve this answer
0

We've used our own PowerShell scripts to do what you're describing. In the Sitecore 8 space -- before SIF -- many organizations built their own automated way of provisioning Sitecore installations. In fact, I think the origins of SIF come from Sitecore's own QA teams provisioning environments on-demand to evaluate features.

You can go through the Sitecore installation document and procedurally complete every step in PowerShell, adding variables where it makes sense (site name, version, etc).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.