This is part 7 of the series of post that I am doing about building a Continuous Integration Environment using Sitecore, TeamCity, Octopus Deploy, and Unicorn.
Part 1 – Setting Up TeamCity
Part 2 – Setting up OctopusDeploy
Part 3 – Setting up SQL Server for Sitecore
Part 4 – IIS
Part 5 – Octopus Environment and Deployment Configuration
Part 6 – TeamCity Project
Part 7 – This post
Part 8 – Sitecore Item Synchronization using Unicorn
Part 9 – Displaying Build number on Sitecore Home Page & Tagging Git
Part 10 – config transformations using Octopus Deploy
Part 11 – Deploying to a Sitecore Multi-Instance Configuration
Assumptions
Just a quick reminder
All the servers are running Windows Server 2012 R2.All the servers are stand alone, and are not part of a domain. All servers have C and D drives.
Everything that is documented here and on subsequent posts are based on freshly installed Windows Servers.
Octopus Project
Start the Octopus Deploy Web Portal
Create Project
From the home page of the portal, select Projects | All
Click Add project
Give the project a name, and select the lifecycle to use.
Click Save
We are now on the Project Home Page
Project Variables
From the project home page, select Variables
I have defined the following variables
| Variable Name | Value | |
|---|---|---|
| website.name | #{Octopus.Project.Name}.#{Octopus.Environment.Name} | |
| base.folder | D:\Websites\#{website.name} | The base folder where the solution will be deployed to. Created a base folder as wanted to keep the website and the data folders separate |
| data.folder | #{base.folder}\data | Where the Sitecore data folder will reside |
| deploy.host | #{Octopus.Project.Name}.#{Octopus.Environment.Name} | |
| website.folder | #{base.folder}\Website | Folder where Sitecore and the solution will be deployed to |
| packageName | This is the name of the NuGet package that has been pushed from TeamCity | |
| sitecore.version | Sitecore_7.2_140526 | The version of sitecore to be deployed from the internal NuGet repository. It must match the NuGet version |
| email.from | The email that the forgotten password is to be sent from. This was discussed in Part 5 when building he version specific NuGet package | |
| smtp.port | ||
| smtp.servername | ||
| smtp.username | ||
| OctopusPrintEvaluatedVariables | False | Handy to keep around because if you need to discuss anything with Octopus they require this value set to True so they can assist you in diagnosing any problems |
| OctopusPrintVariables | False | Handy to keep around because if you need to discuss anything with Octopus they require this value set to True so they can assist you in diagnosing any problems |
Click Save
Process Steps
The process should be fairly simple to set up as everything will be using the steps downloaded from the community or the custom steps templates that where already built. All that will be required is to set the parameters required.
You can create the steps in any order and once you have all the processes you can reorder any step.
Without fail, all the steps will Run on targets CM and CD so unless there is an exception assume that this is the default for each process.
Windows – Ensure Hosts File Entry Exists
I wanted to include this because if you don’t have DNS set up, at least when you call this step, you will ensure that the host name that will be used when the website is created will exist, even if its only on the local machine.
Most administrators are not going to let you automatically create DNS entries so I have not attempted to automate creating entries on a DNS server
From Process, click Add Step
Scroll to select “Windows – Ensure Hosts File Entry Exists”
Set the IP Address to 127.0.0.1
Set Host name to variable #{website.name}
Click Save
IIS AppPool – Stop
This handy process will stop an IIS AppPool. It performs a check to make sure that the AppPool exists before it tries to stop an AppPool. So even though running on first time, it will not cause the process to error
From Process, click Add Step
Scroll to select “IIS AppPool – Stop”
Set the Application pool name to #{website.name}
Set Status check internal to 1000
Set Status check retries to 20
Click Save
Close process locking deployment folder
I have experienced that in the past even when you have stopped a deployment target’s AppPool, locks are still held on the files. This process uses SysInternal’s handle.exe application and will force all locks to be released.
From Process, click Add Step
Scroll to and select “Close Process locking deployment folder”
For Folder where website deploy to enter #{website.folder}
Click Save
File System – Create Web Folder
Make sure that the web site folder exist before starting deployment
From Process, click Add Step
Scroll to and select “File System – Create Folder”
For The folder path to create on the filesystem, enter #{website.folder}
Rename this step to to File System – Create Web Folder as there are going to be more steps that create folders
Click Save
File System – Create Data Folder
Make sure that the data folder that Sitecore will use, exists before starting deployment
From Process, click Add Step
Scroll to and select “File System – Create Folder”
For The folder path to create on the filesystem, enter #{data.folder}
Rename this step to File System – Create Data Folder as there are multiple steps that use this Step Template
Click Save
Copy Sitecore Licence File
This process will ensure that you have the Sitecore Licence file. It will copy the xml file from a shared network folder and will copy it to the data folder. Its great for when you are a partner, and you get your new licence every year. Just always place the latest file on the network share, and it will ensure that the solution will be using the latest file at the next deployment.
From Process, click Add Step
Scroll to and select Copy the Sitecore Licence File
Specify the location where the Licence Key is stored
For Location where the Licence Key is to be copied to enter #{data.Folder}
Click Save
Deploy Base Sitecore Website
This process will deploy the version of Sitecore that the solution is using. It will use the NuGet package that was created previously and uploaded into the Octopus NuGet server.
From Process, click Add Step
Scroll to and select “Deploy Base Sitecore Website”
For Folder where to deploy website to, enter #{website.folder}
Click Save
The Sitecore version installed will be determined based on the value for project variable #{sitecore.version}
Deploy Site
This process will deploy the custom solution onto the version of Sitecore just deployed.
Note
I build my Visual Solutions so that it will not include any of the Sitecore files. If I have to refer to a Sitecore binary, then I have Copy Local set to False. This way I can be sure that when I deploy my solution on top of the Sitecore Solution like what I am doing I know I wont be deploying any Sitecore files when the NuGet file is produced. Obvious exceptions are .config files. These are always included in the NuGet package produced.
From Process, click Add Step
Scroll down to and select “Deploy Site”
For Folder where to deploy website to, enter #{website.folder}
Click Save
IIS AppPool – Create
This process will ensure that the AppPool for the site is created.
From Process, click Add Step
Scroll to and select “IIS AppPool – Create”
For application pool name enter #{website.name}
Depending on your set up you may want to change Identity Type and the specific username and password to use
Click Save
IIS Website – Create
This process will create the website, and will use the AppPool created above.
From Process, click Add Step
Scroll to and select “IIS Website – Create”
Website name, enter #{website.name}
Relative home directory, enter #{website.folder}
Application pool name, enter #{website.name}
Host Header, enter #{website.name}
Ensure that Start the Website is ticked
Click Save
Deploy Sitecore Modules
One of the issues that I have experienced in the past is when you install a Sitecore package. The issue then is that when you deploy on to another another environment these packages are not included. Normally you have to include install multiple packages, and I wanted to group all these steps into a single step.
So want I want to end up with in this step will resemble this
From Process, click Add Step
Scroll down and select “Run a script”
Give the step a name.
For Powershell script enter
Write-Host "Deploy Sitecore Packages-Modules"
Click Save
Load Site
This process is used to load the website. It will not start the website in IIS, but will do a get request for the home page
On the previous step that was created, click on the hamburger menu, and select Add child step
Scroll down and select “Load Site”
All the default values are acceptable as the process will read the value from variable #{website.name}
Click Save
Deploy Sitecore module
On the previous step that was created, click on the hamburger menu, and select Add child step
Scroll down and select “Deploy Sitecore Module-Package”
This step template will be used multiple times, so rename the Step Name. My convention is to include the name of the Sitecore package being deployed.
For Location where the Sitecore Module is Stored, enter the network share where all Sitecore Packages ( this .zip files are located )
For Where to copy the zip file enter #{base.folder}
For Sitecore Module Name, enter the name of the Sitecore package to be installed.
I am deploying the file to be outside the web root and data folders so that it will not be confused by sitecore in any way
Click Save
Repeat this process as many times as required for each Sitecore Package that needs to be installed.
Thoughts
Setting up all the Step Templates makes building up the deployment project extremely simple. There is one caveat though. If you modify a Step Template, then you will to go to every project that is using the custom step and update.
This is what you will see if you edit a step
Depending on the number of projects you have, this may or may not be an issue. For me right now, this is not an issue
If you go to the Step Template in the Library it will list all the projects and steps that use that step
You have to go to each project, and each step within the project and click update. You can leave it. I have left steps needing to be upgraded and have been successfully running deployments with no side effects.
Next Steps
Everything is now set up and configured. The process to deploy a solution from your development machine to your CI environment is complete.
What I will be doing in the next post, is installing and configuring Unicorn created by @kamsar
My musing about anything and everything
The Software Dude 
Well Explained and detailed! Great post!
Just wondering how did you achieve config transformations or variable substitutions for Sitecore patch files?
I’m kind of not liking solutions available for this on internet.
Regards
Sen
Hi Sen
I created another blog post that details how I am using the various config transformation files and variables within Octopus.
config transformations using Octopus Deploy