Getting started with Octopus Deploy

Editor's Notes

• #3 Started out in 2011, now they have over 4,000 customers worldwide.
• #4 Go through schedule Lots of exercises and discussions Does everyone have a laptop?
• #6 No immediate knowledge of when the last deployment was done or who did it. It's time consuming and error prone, not to mention tedious. Devs don’t want to copy files
• #7 The Octopus Deploy Server is where you manage your deployments, projects, environments and machines. It's run as a windows service with an embedded database and an embedded HTTP server running the UI.
• #9 An environment is a group of machines you deploy to at the same time, common examples are Test, Acceptance, Staging and Production.
• #11 Any server you want to deploy code to must run an Octopus Deploy Tentacle. Tentacles run as windows services, and they execute jobs such as deploying a package or running a script when the Octopus Server tells it to.
• #13 A tentacle can run in two modes: Listening or polling. A listening tentacle listens to a TCP port and when the Octopus Server needs to deploy a package it connects to that port. A polling tentacle polls the Octopus Server periodically to check if there are any packages to deploy or scripts to run.   Advantage of listening: Idle most of the time, not taking up any resources, but a port opening and firewall changes are needed.   Advanage of polling: Won't need to open any ports or make any firewall changes, but it uses more resources.
• #14 Machines are any machine you want to deploy to, running an Octopus tentacle. It doesn't matter whether it's an Azure VM or a physical server, they're all viewed upon as "machines". A machine belongs to an environment (or several enviroments, if neccessary).
• #15 When setting up a deployment step, you can assign the step to a certain role. This means that if you have two machines, one with the role app-server and the other with the role web-server, you can configure your web application to only be deployed to the machine with the role web-server while other applications are only deployed to the app-server.
• #21 Projects are the receipe of your deployment. A project is a collection of deployment steps and settings, and together this defines how your application is deployed.
• #22 You can setup project groups to group your projects together logically. You can set user permissions and restrict the available environments per project group.
• #23 Before deploying your applications, they will have to be bundled into NuGet packages which can then be deployed by Octopus. These packages can be hosted in the built-in Octopus repository or in an external NuGet repository.
• #24 Already using Git and TC Go through diagram Last step impossible to specify at this point  
• #27 The deployment process is a series of steps that are executed every time you deploy your application. The steps can be scoped to run in one or several environments, they can be configured to run in parallell and you can define whether a step should be executed regardless of the result of previous steps.   This makes it possible to create steps such as:  "If deploying to the production environment and all previous steps in the deployment process have been successful, email the release notes to the product owner."
• #28 When you create a deployment step, you can choose between several step types. In addition to this, you can create your own step templates, which we'll look into later.
• #29 By default, deployment steps are run in sequence, meaning that one steps finished before the next begins. A -> B -> C   In the newest version of Octopus Deploy, however, it's possible to configure steps to run in parallell.
• #30 If you're deploying to several machines at once, you can use child steps to make sure all steps are executed on one machine before deploying to the next (also called rolling deployment)
• #31 Explain child steps What type of steps are these?
• #32 When you're ready to deploy your code, you create a new release in Octopus Deploy. A release is a snapshot of the current deployment process configuration, variable configuration and the packages chosen for this deployment. A release is typically deployed to one environment and then promoted to the next. This way we're sure there are no differences between the packages or configuration being deployed in the various environments.
• #33 There are always configurational differences between environments. For example, the connection string for your application in Test will be different than the connection string used in production. This is often solved by using config transformation in your project, but in certain cases config transformations are not preferred. Either because product owners don't want sensitive information such as connection string checked into the codebase, or because the configurations don't only vary between environments, but also machines.
• #34 A variable has a name, a value and a scope. Variables can be set as sensitive, resulting in Octopus encrypting them and never revealing the true value again.
• #35 Imagine you have a load balanced web application in production, containing a job that indexes content. There is no need for the indexing job to run on all servers, you actually just want it to run on one of them. As config transformations are scoped to environements, you can use config transforms to enable or disable indexing for ALL the servers, but there's no way of enabling it for some, but not others. In this case, variables in Octopus Deploy come in handy.   This means that we can add an IndexJob variable with the value false, that is scoped to production. You can then add a same instance of the same variable, give it the value true and scope it to the specific machine that needs to run the job.
• #36 Imagine you have a load balanced web application in production, containing a job that indexes content. There is no need for the indexing job to run on all servers, you actually just want it to run on one of them. As config transformations are scoped to environements, you can use config transforms to enable or disable indexing for ALL the servers, but there's no way of enabling it for some, but not others. In this case, variables in Octopus Deploy come in handy.   This means that we can add an IndexJob variable with the value false, that is scoped to production. You can then add a same instance of the same variable, give it the value true and scope it to the specific machine that needs to run the job.
• #37 Built-in variables. In addition to the variables you create yourself, Octopus Deploy contains lots of system variables you can use in your powershell scripts such as: Machine name, Environment names etc.
• #41 Lifecycles are used to set some ground rules as to how your deployment process should be managed. As as example, you wouldn't want a package to be deployed to the production environment before it has been deployed to both test and acceptance, and you can create these rules for your projects by using Lifecycles.
• #43 We can configure this by specifying two phases, containing environments: A phase must be successful before the deploy can move on to the next phase.
• #44 For the example above we can specify that a release will automatically be deployed to Development when the release is created by setting the "Automatically deploy to" setting for the environment in the phase:
• #45 As you create more and more releases, you'll need old releases to clean themselves up. Retention policies define how often releases are deleted, and you can set a retention policy for each phase of a lifecycle or for the project as a whole. The retention policy can be set by the number of releases to keep or the number of days to keep a release.
• #47 Step templates are used to create reusable deployment steps. In other words, deployment steps you can use across several projects at the same time.
• #49 Script modules are used to create reusable PowerShell cmdlets that you can use across several projects at the same time.
• #51 Library variable sets are used to share variables across projects.