Getting started with Octopus Deploy
•Als PPTX, PDF herunterladen•
3 gefällt mir•1,942 views
How do you automate the non-existing deployment routines of an organization with over 100 different customers, each having their own environments? How do you convince the leaders, developers and customers to give you the resources needed in order to automate everything? Is it really possible to introduce a deployment routine that works for everyone? In less than six months, Karoline transformed the deployment routines at Epinova by introducing Octopus Deploy to the organization. She will take you through the steps needed to get started, the pitfalls along the way, and success that Octopus Deploy has become. In this workshop we will start out by installing an Octopus Deploy server and tentacle on your laptop, before looking at the basic concepts of Environments, Machines, Roles and Projects. You will create a project of your own and deploy this using Octopus Deploy before we round off by looking at the advanced topics of Script modules, Step templates, Variable sets and Retention Policies. At the end of this workshop, you'll have all the knowledge you need in order to create a more efficient and failproof deployment process for your project. Keep calm and deploy to production!
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Getting started with Octopus Deploy
Ähnlich wie Getting started with Octopus Deploy (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Getting started with Octopus Deploy
- 1. Getting started with Octopus Deploy Karoline Klever @karolikl karolikl@gmail.com
- 2. “Our mission is to help .NET developers deliver software to production successfully.” – Octopus Deploy
- 3. Schedule • Module 1: The Octopus Deploy Server • Module 2: The Octopus Deploy Tentacles • Module 3: Projects and packages • Module 4: The deployment process • Module 5: Advanced topics
- 4. How? • Discussions • Theory • Exercises
- 5. Discussion: Manual vs Automatic deployments
- 6. Module 1: The Octopus Deploy Server
- 7. Screenshot from demo site: https://demo.octopusdeploy.com/ The Octopus Web Portal
- 8. Environments Screenshot from demo site: https://demo.octopusdeploy.com/app#/environments
- 9. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 1: Installing the Octopus Deploy Server • Exercise 2: Setting up your environments
- 10. Module 2: Octopus Deploy Tenacles
- 11. Tentacles Tentacle Octopus Deploy Server Tentacle Tentacle Tentacle Tentacle Tentacle Azure Website Server with FTP access only
- 12. Tentacle modes • Listening (recommended) • Listens to TCP port • Polling • Polls the Octopus Server periodically
- 13. Machines Screenshot from demo site: https://demo.octopusdeploy.com/app#/environments
- 14. Machine roles Screenshot from demo site: https://demo.octopusdeploy.com/app#/projects/octofx-rate-service/process
- 15. Example Test Production Test server Prod server 1 Prod server 2 Applications: Web Forms Application (runs on test server + 1 production server) ASP.NET MVC Application (runs on test server + both production servers)
- 16. Example Test Production Test server Prod server 1 Prod server 2 Applications: Web Forms Application (runs on test server + 1 production server) Role: forms-server ASP.NET MVC Application (runs on test server + both production servers) Role: web-server
- 17. Example Test Production Test server forms-server & web-server Prod server 1 forms-server & web-server Prod server 2 web-server Applications: Web Forms Application (runs on test server + 1 production server) Role: forms-server ASP.NET MVC Application (runs on test server + both production servers) Role: web-server
- 18. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 3: Installing an Octopus Deploy Tentacle • Exercise 4: Add a machine to the test environment
- 19. Module 3: Projects and Packages
- 20. Projects Screenshot from demo site: https://demo.octopusdeploy.com/app#/projects
- 21. Project groups Screenshot from demo site: https://demo.octopusdeploy.com/app#/projects
- 22. Packages • NuGet packages • Feeds • Built-in Octopus feed • External feed
- 24. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 5: Creating a project • Exercise 6: Uploading a package
- 25. Module 4: The deployment process
- 26. Deployment process Screenshot from demo site: https://demo.octopusdeploy.com/app#/projects/octofx-trading-website/process
- 27. Step types • Deploy a NuGet package • Run a PowerShell script • Send an email • Manual intervention required • Deploy to Windows Azure • Upload files by FTP • ... and you can create your own
- 28. Sequential vs parallel • Sequential • Step A finishes before step B can begin • Default • Parallel • Step A and step B can run at the same time
- 29. Rolling deployments • Run all steps on machine A before running them on machine B • Child steps
- 30. Typical deployment process • 1. Deploy web rolling • 1.1. Remove server from load balancer • 1.2. Deploy web application • 1.3. Warmup web application • 1.4. Add server back to load balancer • 2. Email release notes to product owner
- 31. Releases Screenshot from demo site: https://demo.octopusdeploy.com/app#/projects/octofx-trading-website/releases/2.9.3102
- 32. Variables Screenshot from demo site: https://demo.octopusdeploy.com/app#/library/variables/LibraryVariableSets-1
- 33. Variable • Name • Value • Scope • Environments • Machines • Roles #{VariableName}
- 34. Example • Load balanced application in production, only one server should index content.
- 35. Example • Load balanced application in production, only one server should index content. Name Value Scope RunIndexer false Production RunIndexer true Production; Machine A
- 37. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 7: Defining your deployment process
- 39. Lifecycles Step templates Script modules Library variable sets
- 40. Lifecycles Screenshot from demo site: https://demo.octopusdeploy.com/app#/library/lifecycles/lifecycle-ProjectGroups-1
- 41. Lifecycles allow you to... • ...control the order of deployment from one environment to the next • ...automatically deploy to an environment when a release is created. • ...define the number of releases to keep for each phase of the lifecycle.
- 42. Controlling the order of deployment Example: A project should be deployed to either Development or Test before it's deployed to Production. • Phase 1: Deploy to either Development or Test • Minimum environments before promotion: 1 • Phase 2: Deploy to Production
- 43. Automatically deploy to an environment Example: A release will automatically be deployed to Development when the release is created • Phase 1: Deploy to either Development or Test • Automatically deploy to: Development • Allow manual deployment to: Test • Minimum environments before promotion: 1 • Phase 2: Deploy to Production • Allow manual deployment to: Production
- 44. Define the number of releases to keep Retention policies • Number of releases to keep • Number of days to keep a release
- 45. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 8: Configuring a lifecycle
- 46. Step templates Screenshot from demo site: https://demo.octopusdeploy.com/app#/library/steps/ActionTemplates-1
- 47. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 9: Create a step template
- 48. Script modules Screenshot from demo site: https://demo.octopusdeploy.com/app#/library/scripts/LibraryVariableSets-33
- 49. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 10: Create a script module
- 50. Library variable sets Screenshot from demo site: https://demo.octopusdeploy.com/app#/library/variables/LibraryVariableSets-1
- 51. Lab http://octopusdeploylab.azurewebsites.net/ • Exercise 11: Create a variable set
- 52. Keep in touch! Karoline Klever @karolikl karolikl@gmail.com
Hinweis der Redaktion
- Started out in 2011, now they have over 4,000 customers worldwide.
- Go through schedule Lots of exercises and discussions Does everyone have a laptop?
- 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
- 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.
- An environment is a group of machines you deploy to at the same time, common examples are Test, Acceptance, Staging and Production.
- 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.
- 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.
- 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).
- 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.
- 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.
- You can setup project groups to group your projects together logically. You can set user permissions and restrict the available environments per project group.
- 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.
- Already using Git and TC Go through diagram Last step impossible to specify at this point
- 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."
- 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.
- 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.
- 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)
- Explain child steps What type of steps are these?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- Step templates are used to create reusable deployment steps. In other words, deployment steps you can use across several projects at the same time.
- Script modules are used to create reusable PowerShell cmdlets that you can use across several projects at the same time.
- Library variable sets are used to share variables across projects.