Black Tambourine (Posts tagged Deployment)

1.5M ratings
277k ratings

See, that’s what the app is perfect for.

Sounds perfect Wahhhh, I don’t wanna

Branching, Versioning and Deployment of Sitecore

Here’s quick set of recommendations for setting up your deployment processes with Sitecore once a solution goes live into Production.

Versioning

For versioning I’d recommend the http://semver.org convention of MAJOR.MINOR.PATCH.BUILDNo-BranchName

e.g. 1.2.15.1102-hotfix

Source Control Branches

Branches in source control should be setup as follows:

Master: should be the current production code or code about to be deployed.

Hotfix: should be used for small fixes for production.

Release “A”: larger changes that require a longer period of development and testing.

Each branch is distinguished using a suffix and has it’s own Build Number. The exception is the Master branch, which has no suffix.

The Major.Minor.Patch number reflects which version of Production has been merged into that branch.

When a support/development branch is merged into Master (i.e. ready for Deployment to Production) the version number of Master is incremented (to reflect whether this is a major, minor, or patch change).

This all looks like this over the life of the solution:

image

Channels

Using Octopus Deploy we can create release Channels based on the version numbers suffix. Create a Channel and add a Version Rule. Set the “Tag” filter to be the name of the branch e.g. hotfix. For the Master branch set this value to ^$

Each Channel can have it’s own Lifecycle, so we could set it up so that only the Master branch can be deployed to Production, while others can only go to testing environments.

Sitecores Recommendations

Sitecore have some of their own best practices around deployment, which you can read about on the official Sitecore Helix best practices website: http://helix.sitecore.net/devops/deployment/strategy.html

Sitecore Deployment Versioning Source Control Branching devops Octopus Deploy Channels Team City Build Configuration

Sitecore DLL management with Nuget

When working with a team of developers on a Sitecore project, you’ll want everyone to reference the same version of the Sitecore DLL’s in your solution. Keeping everyone on the same version of the DLL’s when an update to Sitecore occurs and automating the deployment of this can be done using Nuget.

The approach outlined below packages Sitecores DLL’s into a nuget package, and sets CopyLocal to false for all non Content Delivery environments.

This means that deploying a new version to an environment will require you to go through the Sitecore installer; but deployments to the Content Delivery server will deploy the correct DLLs (which normally is a manual step in Sitecore upgrades).

The solution is as follows:

- Make sure that your VS solution has configurations for each environment and that the Content Delivery ones are named ending in “CD” e.g. UATCD.
- Create a nuget package of the Sitecore dlls using NuGet Package Explorer.
- Set the Version number for the particular version of Sitecore e.g. “Sitecore.8.0.0.151127” and add all of the Sitecore dlls to the lib folder of the nuget package.
- Right click, and select “Add Tools Folder” to the package.
- Right click this, and select “Add Install.ps1”.
- edit the ps1 (powershell) file with the following.
- deploy to your nuget server and reference it in your project.

sitecore nuget deployment powershell