Automated release management with TeamCity & OctopusDeploy
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Deinoff, Kristoffer Rolf
Many of us have one or more manual steps in our deploy and release processes. This leads to a lot of time spent waiting for the right people to do the job. Also, errors often occur due to steps forgotten or done incorrectly. This often leads to high walls between the testers, IT-ops and the developers. This talk will start out with some general continuous delivery, the why's, where you'll get to know the actual benefits of applying continuous delivery and the arguments you need to be allowed to spend time on it. Then we will move over to the how's. By demonstrating how you can use TeamCity and OctopusDeploy to configure automated builds and one-click deployment of both an asp.net website and a windows service, and how you can migrate your current manual process into an automated one. Along the way, we will be discussing how OctopusDeploy chooses solves specific problems, and other ways you might handle those issues.
 Hello! Welcome everybody. This is my talk, Automated Release Management with TeamCity and Octopus Deploy. Thank you for coming. I have a lot of slides and a lot to say and something to show, so I'll just start right away. We start about, we have to start with a little bit of history to understand continuous delivery and why we should use it. It started with continuous integration some 10, 15 years ago where we realized that using the version control wasn't enough, so we started adding build servers and running and compiling the code on each check-in and running unit tests and that gave us many advantages and better software for a lot of us. Then they came a blog, talked about continuous deployment, which proposed to use the practices we used for continuous integration but also try to automate the deployment process. After a while, there came a book called Continuous Delivery which tried to take this even further and say that, okay, you are not finished writing your software until you are in release and you should automate everything. And really, it's all about failing fast. If you work for a long time, write a lot of code and then check it in and find a bug. You will have to backtrace a lot, especially if you have, say, implemented five features, you have a bug in the first feature and the next four features rely on the first. Then you have to do everything again. So if you do small incremental changes or small releases, you will have smaller steps to backtrace if something goes wrong. So it's essentially the same logic used for writing unit tests and continuous integration only applied to deploying and releasing. In the book, Continuous Delivery, the first chapter available online, you can find this graph, this chart. It's an image of the deployment pipeline. As you can see on the top, you have your source control which contains your source code and also your environment and app configs. At the bottom, you have the artifact repository which contains all the products of the builds and tests. So with the test reports, test coverage and actual deployment package. You have the commit stage where you compile the code, you run the commit tests. That's the ones that take short enough time to be in this stage. Then you assemble the package and you do some code analysis. If everything is okay, you will automatically deploy and go to the next stage, the acceptance stage. Where you configure and deploy this to your test environment, run a smoke test to see that the website is up and running and then you run your automated acceptance tests. If this goes well, then you will have one, usually one click deployment to the next environment. You have the user acceptance environment where you have some manual testing. You have the capacity stage where you do stress testing and load balancing. It's very important that the capacity stage equals the production stage or the hardware and setup. So it gives you good representation. And then finally, you have the production. This is not what I'm proposing that you should go implement tomorrow. But I use this as a goal when I'm trying to build my deployment pipeline. In the same way that you have on the left, you have Uncle Bob's vision of how your test coverage should be. You can see that you should have 100% unit test coverage, 50% component tests. This, I would also say this, don't go try to implement this at once unless you have a green field project and can start from scratch. If you can reach the one to your right, you should be happy. You should not stop there, but you should at least have that as a first goal. Another thing in continuous deployment is where it is, blue-green deployment. It starts with one version of your system in release. Then you deploy a second version while the first one is still there. And after running smoke tests on all of the servers that you have deployed to, then you just flip a switch and reroute all the users to the new version. This is very good because if something should go wrong, you can just flip the switch back and you don't have any downtime or any significant downtime in your production environment. So Facebook goes a little bit further. They have this big clusters of servers and millions of users. You can imagine what would happen if they made a critical bug into production. Then their reputation would just fall apart. They first release the new versions to an internal part of the servers where only their employees get to test the feature. When they are satisfied with the quality level there, then they deploy it to a small subset of the features. When they are satisfied with that, they deploy it to everybody. Using this way, they can also test the different versions of implementing a new feature and see which one gets the best response and go for that. So the argument for using continuous delivery because you will need some arguments to be able to spend your developing time doing something else than developing. You have the quality argument. In the same way that unit tests increase the potential quality of your software, automating your builds will give you a repeatable reliable way of deploying. So you can remove the manual step, get fewer errors and that gives you higher quality software. You will save money by catching bugs early if you have automated acceptance tests. You will save money because it would take a shorter time to fix them. If you can pick the bug up and the automated acceptance test stage, then if you have to wait a week for the testers to be able to test it. And you have the time aspect. Once you have automated your deployment, it will be automatic. You can just push a button and the time you spent before, you can use doing other stuff. A small example of this, in the background you can see the whiteboard of our key office. They decided to implement this team city octopus deploy solution. Before they started, they had approximately 30 minutes to deploy time. After, they had four minutes. Now they deploy four times a day and they spent initially eight hours of implementing the process. And if you do the math, you have a small equation there which says that if you do this on Friday or during the weekend, then a little bit after lunch on Friday, you will have saved all the time you spent on it originally. And then you will save approximately half an hour each time you click the button. And if you add this, put some numbers on this, multiply it with hours, number of releases you have, maybe the hourly price of a consultant, then you would probably have a strong argument for your superiors for implementing this. So that was the short introduction part. The next part I'm going to use trying on another equation, trying to prove another equation. And we are loading the next slide. Oh. Don't get any internet here. That's sad. Is there any reason for there not being any internet connection on the NDC network? Is there any other network I can use? Okay, we'll try the cable. Now I have a question. Let's see. If I can use the cable. Let's see if we can get this slide up and running. Do I have to reload the entire page? No. Oh, there we are back. I think. I'm sorry for this. I did have the entire slide preloaded before my blue screen, right before the start here. Oh, and there we are back on. Nice. Just took some time. We were at number 15 there. Yeah, the question that I'm going to spend the rest of time on is this one. I'm trying to prove that using TeamCity and OctopusDeploy is a ton of fun. At least I think so. So we're going to start with showing how to deploy a website. We start from scratch and we start in Visual Studio. We create a basic ASP.net website. The only thing I'm going to change is a part of the index page where you can see I have a reference to environment and version. Environments just read an app setting variable from the config file. A version reads the website DLL assembly version. I also have added a couple of additional transform files. You can see this will be the names of the deployment environments. That will make them automatically be transformed when deploying to that environment later. So when we have done that, we will need to create an Octopus package. Octopus negative package. You can see also this is the transform I have for the config transform I have. It only does it finds the environment setting in the app settings and changes it according to the development, to the environment. Just to show that the transforms are working. So we start off by creating the Octopus nugget package. If you wonder why they chose the nugget format, since that is basically a format for our dependencies while library dependencies on their website, they say it's because they have rich metadata. They have lots of available tools for creating them, for managing them and stuff. It's feed-based so you can easily write your own feed. You can easily consume the feed. Developers know how to use them because we use them all the time when developing our own software. It's already used for other purposes. Like chocolatey which is the coolest thing you can come for an apt-get or aptitude for Windows. It's a single command line based installing of packages and software. Another thing you need to be aware of when creating these packages is that it does not follow default nugget conventions. They have some default folder structure and stuff like that. Octopus deploys the package as s. So if you have a website, you just pack that directory and you're good to go. Then you need to add a new spec file. This is being used by nugget to add additional information to your package. The important stuff here is mostly the ID. The version will be overwritten. The title and description are just for description of the package. And the other stuff are just ignored mainly. So you have three ways of creating this package. By far the easiest way is to open the package manager console, type in install package, up the pack. Which is a tool that downloads a target file. It modifies your csprog file to reference this. And it also has executable for creating the package. Then you can just add a parameter in your MS build as run octa pack. And then it will create the package for you. The second way is using team city. They have a nugget pack runner. Which you will then specify your build number, your directory and your output directory. And you can also then select publish created packages to artifacts. In team city. We'll come back to that later. And we will have... This is a snippet from a script you'll see later from a partial script. You can just use the nugget executable directly. And then you specify the file name content there in the version. So there, that's the three ways. Now we're actually finished in visual studio. If you have done that, you're finished and can go over to configuring team city. We were this web project, we will have two build configurations. The first one will be the commit build. We will set this up. We will only change the build number format. I've changed it to a format that I like. This squiggly thing at the end means that the zero will be replaced by this on each, the counter on each build. Then I add a VCS route. I'm connecting to GitHub and this link is live. So we go to GitHub gate pod. Then you can see the source code I've been using for this project. And then in the build steps page, I add a build feature and choose assembly info patcher. What this does by default is running through all your assembly info files before build, replacing the version number with the build number you have. You can also change it, exchange it with other stuff if you'd like that. But the default action is to replace it with the build number. Then you add two build steps. We have the first compile step. It's a visual studio runner type. Select the solution and you have the target rebuild configuration release. That's okay. Then at the bottom I have an extra section because I installed the team city octopus deploy plugin. Then I can just instead of adding the run octopac parameter for MS build, I can just check this box and say that, okay, I want the system build number to be used for the package version as well. Going further, you have the commit tests. It's an unit test runner running all the test DLLs in the release folder excluding the ones in the object folder since they don't have any references and I don't want to run tests twice. Of course, I want to build the trigger on each check-in, so I add an ECS trigger for that. Then we can run the build and it will produce a build artifact. It will produce a NVIDIA package which you can open because it's basically a zip file. You see the project structure. They have a couple of files you don't need to worry about because you will not see them after deployment like the roles and the package and the content types there. Now we are actually complete, but we want to publish this package to a Nugget server. Thankfully, team city has that as well. So you just go into settings and you click the Nugget settings and you click enable Nugget server and then you will get an authenticated feed URL which you will use. If you want to use one of the Nugget tools or team city build tasks, you will need to go to the Nugget command line and download Nugget as well. Download the version or upload it. When we have done that, we go over to octopus deploy because now we need to set up our project. First, we create some environments. As you can see here, you have three environments. We have the development environment located on the build server and we have a separate test and production environments. The way you configure this is install a small service called a tentacle on each of these servers. During the installation process, they will give you this thumb print which you will have to enter in this box when you add a machine to an environment. You give it a name and URL and you say give it a role. We only have one role. We only have one machine. It's a website. I don't have any database servers and I don't have any external other servers. You will also need the thumb print located in the octopus deploy configuration to put in the tentacle config as well to authenticate both ways. Then I do this for the other two servers as well. We can start creating our project. We can just create a new project group and we go to configuration and add a new repository. You can see this is the field, this URL you saw in team city before. I used the username and password that I created for the team city which was in this case build and build. Now I create my project group and project. When I have done that, I go in to create and adding these steps. I'm not going through the first step now because this is just a partial script roughly copied from the octopus deploy documentation page. If you click on partial scripts there, I believe that's where you can find the script. I just changed a couple of few names. This script will be available for you afterwards and in the end I will give you a peek at it. I will go through the published website. You will see here that you choose a new repository and a package. You will get auto completion when you type that. You select which role you want to deploy it to. Then you have some XML configuration. You have two main options. One option is to automatically run configuration transformation files. If you deploy to development environment, then if you have web.development.config, that transformation will be run. And no so on for test release. You can add some additional transforms if you want. If you have some octopus variables with the same name as any app settings, you can also check this box to make them or write it so you don't need the config transforms. And since this is an IAS website, I will say, I will try to automatically update the IAS website with this name, which is a variable that I have set. The smoke test is another just short PowerShell script. It gets the PowerShell variables host name and port and it does a web request to that URL to check that website is up and running. Very basic. And then I have a manual step. We can see that this step is only for the test environment. So in the other environments, this will not be run. You have some instructions. Go to this location and verify only behavior. That's just a very simple description. And it's only users in the testers group that are allowed to do this, perform this step. Developers are not allowed to say that, verify this deployment in the UAT environment. The variables I have are the host name as you see. These are connected to a specific machine, which makes sense. You have the IAS bindings, which uses the port and the host name. This is the way you refer to Octopus deploy variables within Octopus deploy. It's the hash sign and the variable name within brackets. I have an empty variable name here and I have the Octopus website name, which says that you are going to install this website in development as NDC 2013 demo development and the test in test and so on. You have the port 8080 for development, since I have a lot of other service running there. For test and production, that port is 80. But you can see that I can't see. I cannot see and I cannot edit this variable because this is a production variable. This screenshot is taken when I'm logged in as a developer. And I've explicitly set the rights that you're not allowed to see or edit production variables. So that's one way you can get your IT ops department to allow the production configuration, the rest of the production configuration to stay in the source control. And then they and only they can have power over those variables. The permissions are set as following. First you allow the roles that you want and then you tie down. So administrators are allowed to deploy to all environments, developers and testers only to their respective environment and deny everything else. And you can see that Octopus administrators are allowed to view and edit production variables, but no one else is. And then the last step before you go to the user, you want Team City to work as when you start deployments from Team City and you need this API key. Then you can go back to Team City and create the integration build. The integration build is pretty similar, but you can see that the build number format is entirely taken from another variable. The depth means it is dependency. The BT2 is Team City static name for a specific build. You will get, after adding dependency, you will get auto completion when typing in these variable names. So you don't need to guess which name Team City gives the build. And you add a dependency by, I added a snapshot dependency here for retrieving that build number. Then you add Octopus deploy release. This is also a build step that comes with the Octopus deploy team city plugin. You specify the URL of the server, the API key I just mentioned. You name the project, you say the release number you want to have. And if you want to deploy to one or more environments. Since I'm going to have another step running some so called automated integration tests after this, I'm going to wait for the deployment to complete before continuing to the next build step. Which is a PowerShell step. I've added the text that was in this text box in a little more readable way. It is the same stuff that we did in the smoke test. But you have to call it a little bit different. You have to use a web session when calling it from Team City. And that's actually all you need for deploying the website. Let's see if we don't have the connection to Team City here. So I'll try connecting to and to see here again to see if we can get it running. So let's just, we can try to open the build server. All this is set up on three virtual machines running a free version of Windows 7. If anybody wants these machines, and build environment, you can get a copy from me. It's about 17 gigabytes. I have it on this, right? Oh, yeah. And I use the standard password, which is password one. Okay. While waiting to demonstrate that, we can go on with how to deploy a service. The way I choose to select my service is to have another website, asp.net web API self-hosted as a Windows service. I'm not going to go too much into detail how to do that. We're just going to start from, okay, we have a service. We have the application config. We have two other variables, the host name and port. These will be overwritten by the octopus deploy variables later. Since this is not a website, octopus deploy does not know how to install it itself. But if we have a script named deploy.ts1, it will run that when it comes to that part of the deployment process. I have made a partial script library, which is being used by deploy. There. The HTTP API service contains all the magic for self-hosting web API. And I have the same configuration transforms as I had in the last project. I have a new spec file with another different ID. The program which bootstraps the project installer, which is the only important thing is that I need to have the service name the same as the actual service, provided service name here. And I gave the display name the name I want to have in Windows services list. And the rest of the process is almost exactly the same. So I'm not going to go through all the steps once more. I'm just going to go through the differences. So everything I'm not showing in this part of the process is exactly the same as when deploying the website. I have removed one step, the prepare step. And I have the publish service step instead. The thing I've done there is I just unchecked this and removed the text from here because it's not an IAS server. I also have another set of variables and the host name and the port. And now I'm logged in as administrator so we can see the actual port in production. And these variables will be replacing the ones in the app config. And differences in the automated acceptance test here. This URL will return adjacent object containing the environment and the version just like the other website. And I then save the web response in this variable and I check if it contains the correct environment and the connect version. You can see to get a team city variable inside a PowerShell script you use this format and you replace the dots with underscores. So let's see if we got this server up and running. Did we? No, not yet. I can see if we can. It does seem like it. Then we will go on to the next two following scripts uses this configuration file. The structure I've created just for my own purposes. It's about creating packages and publishing them with PowerShell. First file here you can see it takes a couple of parameters, the content directory and the version. You create a new XML object and load the configuration file into that and have a variable containing all the entire configuration structure. I assemble the new spec file name from the config name and I create the entire path which I send to the NuGet pack. You might recognize this from earlier in the presentation. And I catch errors and I have an exit code one to notify the build or release process that this blew up. To publish a NuGet file it's almost the same. You load the configuration now you create the NuGet file name string instead of the new spec. And then I add a NuGet source to the server I want to add. Then I publish that package to that source and I remove that source again because I don't want that source which is my get to end up in whistle studio when I'm trying to get packages and stuff. And I catch an exit one if anything wrong. If you need to create or combine using Team City or now Octopus deploy and MS deploy say that your production environment has a rule that it only accepts MS deploy packages. Then you are able to in your build process create an MS deploy package as well as the Octopus package and you can deploy the package that you would like. So we can still compile once and compile the website or structure and package this into different packages. Then you just have to build up the parameter string which uses a sync content path and package and they use their own config transformations. That's important to know because the MS deploy will not run your regular config transforms. Then you have the deploy PowerShell script that you saw before. That PowerShell script it just sets a service name and service executable. It doesn't infer this because it might be a DLL. In this case it's not. I've created a method install web API service which looks a little bit like this. It tries to get the service. It checks if the service exists in advance. If the service does not exist then it will get the.NET framework directory. It will create the install utl path or command to execute and it will install it. If the service exists it will stop the service and reconfigure the binary path using the sse tool instead. When that's completed you get the port and since this is a web service, no a windows service which want to accept the web requests. This is done automatically by IAS of course but since I don't have the app pool writes and stuff I have to set the url ACL myself. That's what the set user writes. I give the nt authority network service the right to accept all the requests on this given port. The get framework directory is a really simple one. It's just a one liner. It's very nice to have because it will always get the current.NET framework directory. Then you use the url format that the url ACL needs. Then you try to get the current url ACLs. If it exists then you don't have to add the permissions. If it doesn't exist then you will use the net command and add the url ACL for the user to the url. This deploy, oh then you also have the get port. It uses another way of reading the XML file. It finds all the add elements in the app settings and enumerates it through them. It tries to find the one named port and sets the port if it's not found. It just returns the default port. This deploy util ps1 also, I don't have to show that now, but it also contains methods for undoing all these steps for removing the security rights for uninstalling the service. All of the scripts shown or being referenced will be available in another. I will add them to another get repository on my GitHub. Both of the website and the web service are available at GitHub. As I said, if you want to try to test this environment for yourself, you can do that. You can get all of the three virtual machines and go through the things yourself. Let's try to see if it does disconnect the internet now. No, still no connection to the internet. There. Okay. I will try to, look, I can finish the presentation before trying to demonstrate the build and deployment process. So how to get started doing this? Usually, you cannot just implement this. If you are in a green field project or don't have complex deployment routine, then you probably can just go on and put everything and automate everything at once. Most often, that's not the case and you will have to do this manually. The way, or partially manually, step by step, the way you do this is that you first create the environments and projects that you will need. And add all the automated build steps that you can do, like maybe copying files from one server to another. You also have some different deploy steps. That makes this a little bit easier. You can send emails. You can have the manual intervention required. This will be, you will add one of these for all the different manual tasks. So even by creating a deployment process with only manual tasks, you will have a reliable, repeatable deployment process, even though it's not automated. One of the biggest issues, the sources of error in the deployment process is when you do it manually and for God's Step, or do it in one order. So, note that if you don't have access to your deployment or one of the environments, you can run more than one tentacle on the server, just not as a service. You will have to start them manually. But then you can simulate having a production environment and put all the manual steps there. So when you're deploying, you can tick off or click proceed for each step that you want. And you also have ways to connect the issue tracker. In Team City, you have, in the settings in Team City, you have the issue tracker. You can connect things like JIRA, bug track, and one more, I think, very easy. Then you can also integrate the other ways. So you can get Team City built in the status in, for instance, JIRA. So you say here, see here. If you want to connect your issue tracker and it sees that you have an issue key in your checking comments, it will automatically associate it and add it to the build notes. And that was the presentation part of the process. And now let's see if we are lucky with trying to get the deployment or the machines working here. Does anybody have any questions, meanwhile? So we'll try to add a new network bridge with the cable. As I said, there were a lot of slides here and they're all available at slideshare. I will add a Google plus post with the links to the slides, the links to the two repositories, and the links to the scripts that I've told you. And I will also create, if you are not able to copy the entire set of virtual machines after the talk now, I will add torrent for it as well and host it for at least a week or two. So you can download and you can test everything you have seen here in the talk for yourself. Let's see if we are able to go there. So are we having, we're not having any problems here. And we probably need to enable and disable. That's the downside of having to rely on an internet connection for your demo. We see, oh, it's a home network. There's only nice people here. Now can we get somewhere? Yeah. So now this machine is up running. That means we should be able to load the team city build server. And this problem should go away. So, try the Octopus server. Here you can see the slides. Oh, and there we are up and running. Nice. So, that means we can start. It seems like Octopus deploy didn't like very much to be killed like that. So if we just go a little bit down. Oh, yeah, we have to go to the here and we do serve. Open the services and restart. And restart the Octopus service. The Octopus service and oh, it's not even started. It stopped when it started. Try again. Yeah, there we have it. And now we can actually run the deployment part. So, we will log in as a developer first. And here you can see my project. It's the IIS one I'm going to use now. Just have to see that this is disabled. I will have. The one thing about Octopus deploy is that it's free to use for one project. So if you're going to demonstrate two projects, you will have to disable the one you're not showing at the moment. So, and I will go and disable the service here. Now everything should be okay for starting a deployment. So we take the web and we pretend that we have done a change to the source code. And we start the build as we can go and see the build is running. It usually doesn't take that much because I didn't want to add a lot of the code quality stuff. TeamCity has a lot of code quality steps that you can include very, very easily. If you go to build steps and you choose to add a build step, you have things like FX cop. You have inspections and you have duplicates finder, for instance, which are very easy to just add to your project to get some more quality assurance. If we go back to these projects now, we'll probably be, oh, it's running now. Almost complete with the build process. And then when this ticks off, the integration build will start. The integration build will then create a new release here. You can see that the test environment, we, oh, we're not running the test environment. The build environment is up and running. You can see that we are running 10.025. You can also, oh, you don't need the service. So here you see it starting to create the octopus release. If we go for releases now or for an overview, we should see that the development environment will start giving notice that it's being deployed. And it's about halfway through. So. Oh, there we have it. You see that 10.126 has been started deploying. And it was a success. All the steps were finished. If you would like to take a look at it, then you can see all the outputs. You see the XML transforms are being done. You see that it transforms from the properties. And you get the entire content back. Now we would like to promote this to the test environment. That's cool. But I'm logged in as developer, so I'm not allowed to do that. So I can log out and log back in as a tester. Now we will have to have the test machine up and running as well. If I remember correctly, it wasn't up and running a second ago. So we will. Oh, yeah. Because it restarted. And I'm using, I'm not using server OSS on these machines. I'm using the free Windows 7 image you can download yourself to meant for testing older versions of Internet Explorer. So it has, I've activated it. It has a 90-day license. So it's free to use and not giving away illegal software. Yeah, so we go for the test. Okay. Does it have Internet connectivity? Or do we have to play with the, yeah, we think we have to play with the network settings here as well. We can do this for production at the same time though. We log in. The password for all of these are password 1 to log in with a big P. It also will come up as password hint if you type the wrong. Now we should be up and running, I think. So, oh, yeah. We have a home network. We got to choose this. And we cancel this. So now we will get connected. Oh, yeah. And there our test environment should be up and running. And we should see that, oh, that was a build. And this is the test. This is the API. Oh, it's running. When we get this up and running, we can start the push over. So if you go into the project here, we can see the different versions in different environments. You can see a project activity here, which is queued deployment, which requested deployment. You can also have the, take a look at all the steps, the variables. When you set up, for instance, the manual step, as you saw, you don't have very little to actually, well, enter. You only have the approval group and the environment. Oh, there we are up and running. Now we can go to this deployment and we can promote this to the test environment. The only environment we're allowed to deploy. And I deploy this. You can see the current version is 25. And I'll just fix the network thing on the production server meanwhile. Oh, it seems like this is up and running already. Kid it? So now it publishes the website. And when it has done that, it stops. It runs the smoke test. Oh, it's not completely up yet. And soon it's our turn. There. Now the build is in the manual step mode. If you go back and take a look, you see that this build is paused. It will not get further. I chose this as the way to mark user acceptance test failures or successes. So if you do not approve this, you will get a failed build, a failed deployment. What you will do is go to this URL and verify all new behavior. That means that this version number should change. And it did. So we can proceed. Oh, that was the one. It doesn't like the host network changing that much. And we cancel. And we can't do it. And there we should be able to go see if we can get the current version up and running first. So now we have the 26 version deployed to development and test. It will be the same. Oh, here we also have it in release in production, as you can see. And now we can promote this release again. We can promote it to, well, we have to log in as an administrator to be able to purchase the production. The password is simple. It's equal for every all of the octopus users. It's password one, the same as you log into the computer with. Now you can go here and promote this to, now we have all environments. You say production. And we want to deploy that release. And it will do the same thing again. The same process. But now again, excluding the step number four, the manual improvement. Maybe you should want to add the manual improvement of that step as well. Or maybe you want to add a mail, the next step, which sends out a mail to a mailbox or a common user address. And for doing the entire, the same thing for the Windows service is the same. You can also go, if we go to one of the machines, we can say that the service services. And we can open the IIS manager. So you can see how they are installed in this machine. We can also take a look at how octopus uses their packages. You have the octopus folder here. And then application subfolder. This is the environment test. So it has one test environment. And this is the first name of the website. And you have one folder for each of the projects. And you have one folder for each of the releases that has been released there. You can set different retention policies to keep all versions forever. You can set it to keep just the last five versions or the last week's versions or something like that. So we have always can go back a week, but not farther than that. And to just switch from one of these to the other, you just make a redeployment of that to current release. And since it detects that we are already installed, then we just make the switch. And that's how you actually do rollback. And here you can say it has all the configurations, but the web config has been transformed. And if you go to here, you will have the application pools. You have the MDC demo test app pool, which I created with a script. And it would have used the fault app, web application, the fault app pool if I didn't have this partial script in advance. And you have the demo test website. In the services, you have this service with the service name I, and the description that I chose, you can see that it's currently 25. That's the deployed. And you see the service name HTTP API service. And now we should have deployed this all the way to production. I can disable this. And if you would like to watch, we can do the same thing with the service. But this will be the last thing that I'll do. So we will start the service built. Now we can also go into the integration process and see the web and see the results of the integration or this automated acceptance test. This step is a little bit faster because I removed the unit tests step here. So if we go for the integration build here, and it should have started build, there we have one, we can go to the build log. And we can tail it. Now we can see it's finding the project, it's handshaking with the server, creating the release, and now deploying it. So the release 26 has already started. And you can see, oh, it's already deployed. So this one should have environment development and the version 26. If we go to the test and the production. Now I'm logged in as administrators and I'm automatically allowed to deploy this. But then again, now you can see, oh, it's in the correct environment development. This is the small so called automated acceptance test I wrote in PowerShell and it has the correct build number. So my integration build is okay. Let me see if we could have the test. And that will be interesting. We will release this to test. And the deploy to test, it also has the manual stage. It also has the same deploy to the production as you've seen before. But now there's nothing, the rest of the process, nothing new, it's actually the same. So that concludes the talk. And thank you for coming.
 Hello! Welcome everybody. This is my talk, Automated Release Management with TeamCity  and Octopus Deploy. Thank you for coming. I have a lot of slides and a lot to say and  something to show, so I'll just start right away. We start about, we have to start with  a little bit of history to understand continuous delivery and why we should use it. It started  with continuous integration some 10, 15 years ago where we realized that using the version  control wasn't enough, so we started adding build servers and running and compiling the  code on each check-in and running unit tests and that gave us many advantages and better  software for a lot of us. Then they came a blog, talked about continuous deployment,  which proposed to use the practices we used for continuous integration but also try to  automate the deployment process. After a while, there came a book called Continuous Delivery  which tried to take this even further and say that, okay, you are not finished writing  your software until you are in release and you should automate everything.  And really, it's all about failing fast. If you work for a long time, write a lot of code  and then check it in and find a bug. You will have to backtrace a lot, especially if you  have, say, implemented five features, you have a bug in the first feature and the next  four features rely on the first. Then you have to do everything again. So if you do  small incremental changes or small releases, you will have smaller steps to backtrace if  something goes wrong. So it's essentially the same logic used for writing unit tests  and continuous integration only applied to deploying and releasing.  In the book, Continuous Delivery, the first chapter available online, you can find this  graph, this chart. It's an image of the deployment pipeline. As you can see on the top, you have  your source control which contains your source code and also your environment and app configs.  At the bottom, you have the artifact repository which contains all the products of the builds  and tests. So with the test reports, test coverage and actual deployment package. You  have the commit stage where you compile the code, you run the commit tests. That's the  ones that take short enough time to be in this stage. Then you assemble the package and  you do some code analysis. If everything is okay, you will automatically deploy and go  to the next stage, the acceptance stage. Where you configure and deploy this to your test  environment, run a smoke test to see that the website is up and running and then you run  your automated acceptance tests. If this goes well, then you will have one, usually one  click deployment to the next environment. You have the user acceptance environment where  you have some manual testing. You have the capacity stage where you do stress testing  and load balancing. It's very important that the capacity stage equals the production stage  or the hardware and setup. So it gives you good representation. And then finally, you  have the production. This is not what I'm proposing that you should go implement tomorrow.  But I use this as a goal when I'm trying to build my deployment pipeline. In the same  way that you have on the left, you have Uncle Bob's vision of how your test coverage should  be. You can see that you should have 100% unit test coverage, 50% component tests. This,  I would also say this, don't go try to implement this at once unless you have a green field  project and can start from scratch. If you can reach the one to your right, you should  be happy. You should not stop there, but you should at least have that as a first goal.  Another thing in continuous deployment is where it is, blue-green deployment. It starts  with one version of your system in release. Then you deploy a second version while the  first one is still there. And after running smoke tests on all of the servers that you  have deployed to, then you just flip a switch and reroute all the users to the new version.  This is very good because if something should go wrong, you can just flip the switch back  and you don't have any downtime or any significant downtime in your production environment.  So Facebook goes a little bit further. They have this big clusters of servers and millions  of users. You can imagine what would happen if they made a critical bug into production.  Then their reputation would just fall apart. They first release the new versions to an  internal part of the servers where only their employees get to test the feature. When they  are satisfied with the quality level there, then they deploy it to a small subset of the  features. When they are satisfied with that, they deploy it to everybody. Using this way,  they can also test the different versions of implementing a new feature and see which  one gets the best response and go for that. So the argument for using continuous delivery  because you will need some arguments to be able to spend your developing time doing something  else than developing. You have the quality argument. In the same way that unit tests  increase the potential quality of your software, automating your builds will give you a repeatable  reliable way of deploying. So you can remove the manual step, get fewer errors and that  gives you higher quality software. You will save money by catching bugs early if you have  automated acceptance tests. You will save money because it would take a shorter time  to fix them. If you can pick the bug up and the automated acceptance test stage, then  if you have to wait a week for the testers to be able to test it. And you have the time  aspect. Once you have automated your deployment, it will be automatic. You can just push a  button and the time you spent before, you can use doing other stuff. A small example  of this, in the background you can see the whiteboard of our key office. They decided  to implement this team city octopus deploy solution. Before they started, they had approximately  30 minutes to deploy time. After, they had four minutes. Now they deploy four times a  day and they spent initially eight hours of implementing the process. And if you do the  math, you have a small equation there which says that if you do this on Friday or during  the weekend, then a little bit after lunch on Friday, you will have saved all the time  you spent on it originally. And then you will save approximately half an hour each time  you click the button. And if you add this, put some numbers on this, multiply it with  hours, number of releases you have, maybe the hourly price of a consultant, then you  would probably have a strong argument for your superiors for implementing this.  So that was the short introduction part. The next part I'm going to use trying on another  equation, trying to prove another equation. And we are loading the next slide.  Oh. Don't get any internet here. That's sad. Is there any reason for there not being any  internet connection on the NDC network? Is there any other network I can use?  Okay, we'll try the cable. Now I have a question. Let's see. If I can use the  cable. Let's see if we can get this slide up and running. Do I have to reload the entire  page? No. Oh, there we are back. I think.  I'm sorry for this. I did have the entire slide preloaded before my blue screen, right  before the start here. Oh, and there we are back on. Nice. Just took some time. We were  at number 15 there. Yeah, the question that I'm going to spend the rest of time on is  this one. I'm trying to prove that using TeamCity and OctopusDeploy is a ton of fun. At least  I think so. So we're going to start with showing how to deploy a website. We start from scratch  and we start in Visual Studio. We create a basic ASP.net website. The only thing I'm  going to change is a part of the index page where you can see I have a reference to environment  and version. Environments just read an app setting variable from the config file. A version  reads the website DLL assembly version. I also have added a couple of additional transform  files. You can see this will be the names of the deployment environments. That will  make them automatically be transformed when deploying to that environment later. So when  we have done that, we will need to create an Octopus package. Octopus negative package.  You can see also this is the transform I have for the config transform I have. It only does  it finds the environment setting in the app settings and changes it according to the development,  to the environment. Just to show that the transforms are working. So we start off by  creating the Octopus nugget package. If you wonder why they chose the nugget format, since  that is basically a format for our dependencies while library dependencies on their website,  they say it's because they have rich metadata. They have lots of available tools for creating  them, for managing them and stuff. It's feed-based so you can easily write your own feed. You  can easily consume the feed. Developers know how to use them because we use them all the  time when developing our own software. It's already used for other purposes. Like chocolatey  which is the coolest thing you can come for an apt-get or aptitude for Windows. It's a  single command line based installing of packages and software. Another thing you need to be  aware of when creating these packages is that it does not follow default nugget conventions.  They have some default folder structure and stuff like that. Octopus deploys the package  as s. So if you have a website, you just pack that directory and you're good to go.  Then you need to add a new spec file. This is being used by nugget to add additional  information to your package. The important stuff here is mostly the ID. The version  will be overwritten. The title and description are just for description of the package. And  the other stuff are just ignored mainly. So you have three ways of creating this package.  By far the easiest way is to open the package manager console, type in install package,  up the pack. Which is a tool that downloads a target file. It modifies your csprog file  to reference this. And it also has executable for creating the package. Then you can just  add a parameter in your MS build as run octa pack. And then it will create the package  for you. The second way is using team city. They have a nugget pack runner. Which you  will then specify your build number, your directory and your output directory. And you  can also then select publish created packages to artifacts. In team city. We'll come back  to that later. And we will have... This is a snippet from a script you'll see later from  a partial script. You can just use the nugget executable directly. And then you specify  the file name content there in the version. So there, that's the three ways. Now we're  actually finished in visual studio. If you have done that, you're finished and can go  over to configuring team city. We were this web project, we will have two build configurations.  The first one will be the commit build. We will set this up. We will only change the  build number format. I've changed it to a format that I like. This squiggly thing at the end  means that the zero will be replaced by this on each, the counter on each build. Then I  add a VCS route. I'm connecting to GitHub and this link is live. So we go to GitHub  gate pod. Then you can see the source code I've been using for this project. And then  in the build steps page, I add a build feature and choose assembly info patcher. What this  does by default is running through all your assembly info files before build, replacing  the version number with the build number you have. You can also change it, exchange it  with other stuff if you'd like that. But the default action is to replace it with the  build number. Then you add two build steps. We have the first compile step. It's a visual  studio runner type. Select the solution and you have the target rebuild configuration  release. That's okay. Then at the bottom I have an extra section because I installed  the team city octopus deploy plugin. Then I can just instead of adding the run octopac  parameter for MS build, I can just check this box and say that, okay, I want the system  build number to be used for the package version as well. Going further, you have the commit  tests. It's an unit test runner running all the test DLLs in the release folder excluding  the ones in the object folder since they don't have any references and I don't want to run  tests twice. Of course, I want to build the trigger on each check-in, so I add an ECS  trigger for that. Then we can run the build and it will produce a build artifact. It will  produce a NVIDIA package which you can open because it's basically a zip file. You see  the project structure. They have a couple of files you don't need to worry about because  you will not see them after deployment like the roles and the package and the content  types there. Now we are actually complete, but we want to publish this package to a Nugget  server. Thankfully, team city has that as well. So you just go into settings and you  click the Nugget settings and you click enable Nugget server and then you will get an authenticated  feed URL which you will use. If you want to use one of the Nugget tools or team city build  tasks, you will need to go to the Nugget command line and download Nugget as well. Download  the version or upload it. When we have done that, we go over to octopus deploy because  now we need to set up our project. First, we create some environments. As you can see  here, you have three environments. We have the development environment located on the  build server and we have a separate test and production environments. The way you configure  this is install a small service called a tentacle on each of these servers. During the installation  process, they will give you this thumb print which you will have to enter in this box when  you add a machine to an environment. You give it a name and URL and you say give it a role.  We only have one role. We only have one machine. It's a website. I don't have any database  servers and I don't have any external other servers. You will also need the thumb print  located in the octopus deploy configuration to put in the tentacle config as well to authenticate  both ways. Then I do this for the other two servers as well. We can start creating our  project. We can just create a new project group and we go to configuration and add a  new repository. You can see this is the field, this URL you saw in team city before. I used  the username and password that I created for the team city which was in this case build  and build. Now I create my project group and project. When I have done that, I go in to  create and adding these steps. I'm not going through the first step now because this is  just a partial script roughly copied from the octopus deploy documentation page. If you  click on partial scripts there, I believe that's where you can find the script. I just  changed a couple of few names. This script will be available for you afterwards and in  the end I will give you a peek at it. I will go through the published website. You will  see here that you choose a new repository and a package. You will get auto completion  when you type that. You select which role you want to deploy it to. Then you have some  XML configuration. You have two main options. One option is to automatically run configuration  transformation files. If you deploy to development environment, then if you have web.development.config,  that transformation will be run. And no so on for test release. You can add some additional  transforms if you want. If you have some octopus variables with the same name as any app settings,  you can also check this box to make them or write it so you don't need the config transforms.  And since this is an IAS website, I will say, I will try to automatically update the IAS  website with this name, which is a variable that I have set. The smoke test is another  just short PowerShell script. It gets the PowerShell variables host name and port and  it does a web request to that URL to check that website is up and running. Very basic.  And then I have a manual step. We can see that this step is only for the test environment.  So in the other environments, this will not be run. You have some instructions. Go to  this location and verify only behavior. That's just a very simple description. And it's  only users in the testers group that are allowed to do this, perform this step. Developers  are not allowed to say that, verify this deployment in the UAT environment. The variables I have  are the host name as you see. These are connected to a specific machine, which makes sense.  You have the IAS bindings, which uses the port and the host name. This is the way you  refer to Octopus deploy variables within Octopus deploy. It's the hash sign and the variable  name within brackets. I have an empty variable name here and I have the Octopus website name,  which says that you are going to install this website in development as NDC 2013 demo development  and the test in test and so on. You have the port 8080 for development, since I have a  lot of other service running there. For test and production, that port is 80. But you can  see that I can't see. I cannot see and I cannot edit this variable because this is a production  variable. This screenshot is taken when I'm logged in as a developer. And I've explicitly  set the rights that you're not allowed to see or edit production variables. So that's  one way you can get your IT ops department to allow the production configuration, the  rest of the production configuration to stay in the source control. And then they and only  they can have power over those variables. The permissions are set as following. First  you allow the roles that you want and then you tie down. So administrators are allowed  to deploy to all environments, developers and testers only to their respective environment  and deny everything else. And you can see that Octopus administrators are allowed to  view and edit production variables, but no one else is. And then the last step before  you go to the user, you want Team City to work as when you start deployments from Team  City and you need this API key. Then you can go back to Team City and create the integration  build. The integration build is pretty similar, but you can see that the build number format  is entirely taken from another variable. The depth means it is dependency. The BT2 is Team  City static name for a specific build. You will get, after adding dependency, you will  get auto completion when typing in these variable names. So you don't need to guess which name  Team City gives the build. And you add a dependency by, I added a snapshot dependency here for  retrieving that build number. Then you add Octopus deploy release. This is also a build  step that comes with the Octopus deploy team city plugin. You specify the URL of the server,  the API key I just mentioned. You name the project, you say the release number you want  to have. And if you want to deploy to one or more environments. Since I'm going to have  another step running some so called automated integration tests after this, I'm going to  wait for the deployment to complete before continuing to the next build step. Which is  a PowerShell step. I've added the text that was in this text box in a little more readable  way. It is the same stuff that we did in the smoke test. But you have to call it a little  bit different. You have to use a web session when calling it from Team City. And that's  actually all you need for deploying the website. Let's see if we don't have the connection  to Team City here. So I'll try connecting to and to see here again to see if we can  get it running. So let's just, we can try to open the build server. All this is set up  on three virtual machines running a free version of Windows 7. If anybody wants these machines,  and build environment, you can get a copy from me. It's about 17 gigabytes. I have it on  this, right? Oh, yeah. And I use the standard password, which is password one. Okay. While  waiting to demonstrate that, we can go on with how to deploy a service. The way I choose  to select my service is to have another website, asp.net web API self-hosted as a Windows  service. I'm not going to go too much into detail how to do that. We're just going to  start from, okay, we have a service. We have the application config. We have two other  variables, the host name and port. These will be overwritten by the octopus deploy variables  later. Since this is not a website, octopus deploy does not know how to install it itself.  But if we have a script named deploy.ts1, it will run that when it comes to that part  of the deployment process. I have made a partial script library, which is being used by deploy.  There. The HTTP API service contains all the magic for self-hosting web API. And I have  the same configuration transforms as I had in the last project. I have a new spec file  with another different ID. The program which bootstraps the project installer, which is  the only important thing is that I need to have the service name the same as the actual  service, provided service name here. And I gave the display name the name I want to have  in Windows services list. And the rest of the process is almost exactly the same. So I'm  not going to go through all the steps once more. I'm just going to go through the differences.  So everything I'm not showing in this part of the process is exactly the same as when  deploying the website. I have removed one step, the prepare step. And I have the publish  service step instead. The thing I've done there is I just unchecked this and removed  the text from here because it's not an IAS server. I also have another set of variables  and the host name and the port. And now I'm logged in as administrator so we can see the  actual port in production. And these variables will be replacing the ones in the app config.  And differences in the automated acceptance test here. This URL will return adjacent object  containing the environment and the version just like the other website. And I then save  the web response in this variable and I check if it contains the correct environment and  the connect version. You can see to get a team city variable inside a PowerShell script  you use this format and you replace the dots with underscores. So let's see if we got this  server up and running. Did we? No, not yet. I can see if we can. It does seem like it.  Then we will go on to the next two following scripts uses this configuration file. The  structure I've created just for my own purposes. It's about creating packages and publishing  them with PowerShell. First file here you can see it takes a couple of parameters, the  content directory and the version. You create a new XML object and load the configuration  file into that and have a variable containing all the entire configuration structure. I  assemble the new spec file name from the config name and I create the entire path which I  send to the NuGet pack. You might recognize this from earlier in the presentation. And  I catch errors and I have an exit code one to notify the build or release process that  this blew up. To publish a NuGet file it's almost the same. You load the configuration  now you create the NuGet file name string instead of the new spec. And then I add a NuGet source  to the server I want to add. Then I publish that package to that source and I remove that  source again because I don't want that source which is my get to end up in whistle studio  when I'm trying to get packages and stuff. And I catch an exit one if anything wrong.  If you need to create or combine using Team City or now Octopus deploy and MS deploy say  that your production environment has a rule that it only accepts MS deploy packages. Then  you are able to in your build process create an MS deploy package as well as the Octopus  package and you can deploy the package that you would like. So we can still compile once  and compile the website or structure and package this into different packages. Then you just  have to build up the parameter string which uses a sync content path and package and they  use their own config transformations. That's important to know because the MS deploy will  not run your regular config transforms. Then you have the deploy PowerShell script that  you saw before. That PowerShell script it just sets a service name and service executable.  It doesn't infer this because it might be a DLL. In this case it's not. I've created  a method install web API service which looks a little bit like this. It tries to get the  service. It checks if the service exists in advance. If the service does not exist then  it will get the.NET framework directory. It will create the install utl path or command  to execute and it will install it. If the service exists it will stop the service and  reconfigure the binary path using the sse tool instead. When that's completed you get  the port and since this is a web service, no a windows service which want to accept  the web requests. This is done automatically by IAS of course but since I don't have the  app pool writes and stuff I have to set the url ACL myself. That's what the set user writes.  I give the nt authority network service the right to accept all the requests on this given  port. The get framework directory is a really simple one. It's just a one liner. It's very  nice to have because it will always get the current.NET framework directory. Then you  use the url format that the url ACL needs. Then you try to get the current url ACLs.  If it exists then you don't have to add the permissions. If it doesn't exist then you  will use the net command and add the url ACL for the user to the url. This deploy, oh  then you also have the get port. It uses another way of reading the XML file. It finds all  the add elements in the app settings and enumerates it through them. It tries to find the one  named port and sets the port if it's not found. It just returns the default port. This deploy  util ps1 also, I don't have to show that now, but it also contains methods for undoing all  these steps for removing the security rights for uninstalling the service. All of the scripts  shown or being referenced will be available in another. I will add them to another get  repository on my GitHub. Both of the website and the web service are available at GitHub.  As I said, if you want to try to test this environment for yourself, you can do that.  You can get all of the three virtual machines and go through the things yourself. Let's  try to see if it does disconnect the internet now. No, still no connection to the internet.  There. Okay. I will try to, look, I can finish the presentation before trying to demonstrate  the build and deployment process. So how to get started doing this? Usually, you cannot  just implement this. If you are in a green field project or don't have complex deployment  routine, then you probably can just go on and put everything and automate everything at  once. Most often, that's not the case and you will have to do this manually. The way,  or partially manually, step by step, the way you do this is that you first create the environments  and projects that you will need. And add all the automated build steps that you can do,  like maybe copying files from one server to another. You also have some different deploy  steps. That makes this a little bit easier. You can send emails. You can have the manual  intervention required. This will be, you will add one of these for all the different manual  tasks. So even by creating a deployment process with only manual tasks, you will have a reliable,  repeatable deployment process, even though it's not automated. One of the biggest issues,  the sources of error in the deployment process is when you do it manually and for God's  Step, or do it in one order. So, note that if you don't have access to your deployment  or one of the environments, you can run more than one tentacle on the server, just not  as a service. You will have to start them manually. But then you can simulate having  a production environment and put all the manual steps there. So when you're deploying, you  can tick off or click proceed for each step that you want.  And you also have ways to connect the issue tracker. In Team City, you have, in the settings  in Team City, you have the issue tracker. You can connect things like JIRA, bug track,  and one more, I think, very easy. Then you can also integrate the other ways. So you  can get Team City built in the status in, for instance, JIRA. So you say here, see here.  If you want to connect your issue tracker and it sees that you have an issue key in your  checking comments, it will automatically associate it and add it to the build notes. And that  was the presentation part of the process. And now let's see if we are lucky with trying  to get the deployment or the machines working here. Does anybody have any questions, meanwhile?  So we'll try to add a new network bridge with the cable. As I said, there were a lot of  slides here and they're all available at slideshare. I will add a Google plus post with the links  to the slides, the links to the two repositories, and the links to the scripts that I've told  you. And I will also create, if you are not able to copy the entire set of virtual machines  after the talk now, I will add torrent for it as well and host it for at least a week  or two. So you can download and you can test everything you have seen here in the talk  for yourself. Let's see if we are able to go there. So are we having, we're not having  any problems here. And we probably need to enable and disable. That's the downside of  having to rely on an internet connection for your demo. We see, oh, it's a home network.  There's only nice people here. Now can we get somewhere? Yeah. So now this machine is up  running. That means we should be able to load the team city build server. And this problem  should go away. So, try the Octopus server. Here you can see the slides. Oh, and there  we are up and running. Nice. So, that means we can start. It seems like Octopus deploy  didn't like very much to be killed like that. So if we just go a little bit down. Oh, yeah,  we have to go to the here and we do serve. Open the services and restart. And restart  the Octopus service. The Octopus service and oh, it's not even started. It stopped when  it started. Try again. Yeah, there we have it. And now we can actually run the deployment  part. So, we will log in as a developer first. And here you can see my project. It's the  IIS one I'm going to use now. Just have to see that this is disabled. I will have. The  one thing about Octopus deploy is that it's free to use for one project. So if you're  going to demonstrate two projects, you will have to disable the one you're not showing  at the moment. So, and I will go and disable the service here. Now everything should be  okay for starting a deployment. So we take the web and we pretend that we have done a  change to the source code. And we start the build as we can go and see the build is running.  It usually doesn't take that much because I didn't want to add a lot of the code quality  stuff. TeamCity has a lot of code quality steps that you can include very, very easily.  If you go to build steps and you choose to add a build step, you have things like FX  cop. You have inspections and you have duplicates finder, for instance, which are very easy  to just add to your project to get some more quality assurance. If we go back to these  projects now, we'll probably be, oh, it's running now. Almost complete with the build  process. And then when this ticks off, the integration build will start. The integration  build will then create a new release here. You can see that the test environment, we,  oh, we're not running the test environment. The build environment is up and running. You  can see that we are running 10.025. You can also, oh, you don't need the service. So here  you see it starting to create the octopus release. If we go for releases now or for an overview,  we should see that the development environment will start giving notice that it's being deployed.  And it's about halfway through. So.  Oh, there we have it. You see that 10.126 has been started deploying. And it was a success.  All the steps were finished. If you would like to take a look at it, then you can see all  the outputs. You see the XML transforms are being done. You see that it transforms from  the properties. And you get the entire content back. Now we would like to promote this to  the test environment. That's cool. But I'm logged in as developer, so I'm not allowed  to do that. So I can log out and log back in as a tester. Now we will have to have the  test machine up and running as well. If I remember correctly, it wasn't up and running  a second ago. So we will. Oh, yeah. Because it restarted. And I'm using, I'm not using  server OSS on these machines. I'm using the free Windows 7 image you can download yourself  to meant for testing older versions of Internet Explorer. So it has, I've activated it. It  has a 90-day license. So it's free to use and not giving away illegal software. Yeah,  so we go for the test. Okay. Does it have Internet connectivity? Or do we have to play  with the, yeah, we think we have to play with the network settings here as well. We can  do this for production at the same time though. We log in. The password for all of these are  password 1 to log in with a big P. It also will come up as password hint if you type  the wrong. Now we should be up and running, I think. So, oh, yeah. We have a home network.  We got to choose this. And we cancel this. So now we will get connected. Oh, yeah. And  there our test environment should be up and running. And we should see that, oh, that  was a build. And this is the test. This is the API. Oh, it's running. When we get this  up and running, we can start the push over. So if you go into the project here, we can  see the different versions in different environments. You can see a project activity here, which  is queued deployment, which requested deployment. You can also have the, take a look at all  the steps, the variables. When you set up, for instance, the manual step, as you saw,  you don't have very little to actually, well, enter. You only have the approval group and  the environment. Oh, there we are up and running. Now we can go to this deployment and we can  promote this to the test environment. The only environment we're allowed to deploy.  And I deploy this. You can see the current version is 25. And I'll just fix the network  thing on the production server meanwhile. Oh, it seems like this is up and running already.  Kid it? So now it publishes the website. And when it has done that, it stops. It runs  the smoke test. Oh, it's not completely up yet. And soon it's our turn. There. Now the  build is in the manual step mode. If you go back and take a look, you see that this build  is paused. It will not get further. I chose this as the way to mark user acceptance test  failures or successes. So if you do not approve this, you will get a failed build, a failed  deployment. What you will do is go to this URL and verify all new behavior. That means  that this version number should change. And it did. So we can proceed. Oh, that was the  one. It doesn't like the host network changing that much. And we cancel. And we can't do  it. And there we should be able to go see if we can get the current version up and running  first. So now we have the 26 version deployed to development and test. It will be the same.  Oh, here we also have it in release in production, as you can see. And now we can promote this  release again. We can promote it to, well, we have to log in as an administrator to be  able to purchase the production. The password is simple. It's equal for every all of the  octopus users. It's password one, the same as you log into the computer with. Now you  can go here and promote this to, now we have all environments. You say production. And  we want to deploy that release. And it will do the same thing again. The same process.  But now again, excluding the step number four, the manual improvement. Maybe you should want  to add the manual improvement of that step as well. Or maybe you want to add a mail, the  next step, which sends out a mail to a mailbox or a common user address. And for doing the  entire, the same thing for the Windows service is the same. You can also go, if we go to  one of the machines, we can say that the service services. And we can open the IIS manager.  So you can see how they are installed in this machine. We can also take a look at how octopus  uses their packages. You have the octopus folder here. And then application subfolder.  This is the environment test. So it has one test environment. And this is the first name  of the website. And you have one folder for each of the projects. And you have one folder  for each of the releases that has been released there. You can set different retention policies  to keep all versions forever. You can set it to keep just the last five versions or the  last week's versions or something like that. So we have always can go back a week, but  not farther than that. And to just switch from one of these to the other, you just make  a redeployment of that to current release. And since it detects that we are already installed,  then we just make the switch. And that's how you actually do rollback. And here you can  say it has all the configurations, but the web config has been transformed. And if you  go to here, you will have the application pools. You have the MDC demo test app pool,  which I created with a script. And it would have used the fault app, web application,  the fault app pool if I didn't have this partial script in advance. And you have the demo test  website. In the services, you have this service with the service name I, and the description  that I chose, you can see that it's currently 25. That's the deployed. And you see the service  name HTTP API service. And now we should have deployed this all the way to production. I  can disable this. And if you would like to watch, we can do the same thing with the service.  But this will be the last thing that I'll do. So we will start the service built. Now we  can also go into the integration process and see the web and see the results of the integration  or this automated acceptance test. This step is a little bit faster because I removed the  unit tests step here. So if we go for the integration build here, and it should have  started build, there we have one, we can go to the build log. And we can tail it. Now we  can see it's finding the project, it's handshaking with the server, creating the release, and  now deploying it. So the release 26 has already started. And you can see, oh, it's already  deployed. So this one should have environment development and the version 26. If we go to  the test and the production. Now I'm logged in as administrators and I'm automatically  allowed to deploy this. But then again, now you can see, oh, it's in the correct environment  development. This is the small so called automated acceptance test I wrote in PowerShell and it  has the correct build number. So my integration build is okay. Let me see if we could have  the test. And that will be interesting. We will release this to test. And the deploy  to test, it also has the manual stage. It also has the same deploy to the production  as you've seen before. But now there's nothing, the rest of the process, nothing new, it's  actually the same. So that concludes the talk. And thank you for coming.
Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_0_107.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_108_155.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_156_203.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_204_251.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_252_299.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_300_13415.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_13416_13859.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_13860_13955.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_13956_14027.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_14028_15239.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_15240_15299.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_15300_15383.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_15384_15551.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_15552_15755.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_15756_15971.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_15972_16223.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_16224_16319.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_16320_16463.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_16464_17183.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_17184_17267.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_17268_17435.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_17436_40895.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_40896_40979.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_40980_41423.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_41424_42455.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_42456_42503.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_42504_47267.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_47268_47375.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_47376_47435.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_47436_47591.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_47592_47735.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_47736_47855.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_47856_47915.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_47916_57395.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_57396_57791.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_57792_57935.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_57936_58055.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_58056_62315.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_62316_62387.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_62388_62519.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_62520_62747.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_62748_63119.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_63120_63335.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_63336_63683.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_63684_63731.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_63732_65027.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_65028_65183.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_65184_65267.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_65268_65351.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_65352_65447.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_65448_65495.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_65496_66503.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_66504_66587.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_66588_66791.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_66792_67079.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67080_67295.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67296_67415.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67416_67523.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67524_67595.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67596_67775.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67776_67847.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67848_67931.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67932_67979.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_67980_68207.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_68208_68963.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_68964_69275.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_69276_69323.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_69324_69407.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_69408_69563.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_69564_76883.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_76884_77099.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_77100_78611.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_78612_78755.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_78756_81947.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_81948_82055.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_82056_84635.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_84636_84695.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_84696_92075.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_92076_95915.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_95916_95987.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_95988_97211.png Kristoffer_Rolf_Deinoff_-_Automated_release_management_with_TeamCity___OctopusDeploy-68383404_97212_97308.png