As a minimum (for this) you will want the following packages:
You should source control this solution as per other posts, but note you don’t want to source control the umbraco or umbraco_clients directories.
The Teamcity build should have two steps:
- Nuget the packages from the repo
- Build the project (and package with OctoDeploy)
A standard umbraco build doesn’t include the umbraco, or umbraco_client folders in the solution, this then means they don’t then appear in the octopus deploy nuget package .
If you put a .nuspec file in the root of the project (with the same name as the project) you can then add extra files - via the files section of the file. When OctoPack runs it will add any files in this section to the build.
If you do a deploy of Umbraco using WebDeploy these folders are included through the use of a .target file. (/packages/UmbracoCms.x/Build/UmbracoCms.targets). This .nuspec file tells octopack to copy the same files into our package.
<file src=”App_Browsers*\“ target=”App_Browsers” />
<file src=”Config\Splashes*\“ target=”Config\Splashes” />
<file src=”Umbraco*\.“ target=”Umbraco” />
<file src=”Umbraco_Client**\.*” target=”Umbraco_Client” />
Using this section in your .nuspec file means you will get umbraco on the destination server.
If you are also using uSync you will want to add the uSync files to this section:
This will mean uSync also gets its files copied to the build without you needing to add anything to your solution file
_Corrupt .nuget package? It’s quite common if you (or someone on your development team) haven’t worked with deploy targets before, that you will be tempted to add the umbraco or umbraco_client folder to your solution. DON’T DO THIS! If you do octopack will include the files in the project and those in the .nuspec file and you will end up with duplicates inside your package. Octopus will then refuse to deploy this, and you will be left scratching your head wondering why. _
Once you have an octopack with all the files in it you can use octopus deploy to get the site onto the server. There is very little extra configuration here, although it’s good to have scripts to increment the clientdependency version and ideally clean the usync folder before the deployment, so you don’t get any rogue files hanging around after deletion.