Home / IT & Computer Science / Business Technology / Microsoft Future Ready: Continuous Integration Implementation / Automated Deployments Using Release Manager
Automated Deployments Using Release Manager
.
[SOFT MUSIC]
Hello. And welcome back to this video on automated deployment using Release Manager. In the previous video, we saw how we can provision infrastructure using a Azure resource group template that we created within Visual Studio. In this video, we’ll take it a step forward by layering our application on top of the newly provisioned infrastructure. We’ll do that by creating a new– by appending a couple of more tasks to an existing build pipeline that we have created. And you’d be happy to know that there is out-of-box support for deploying web apps. There is out-of-box support for rolling out databases. But along with this, there is third-party vendor support as well as open source support.
So if you’re using products from Redgate, then you’d be pleased to know that they ship one of their extensions to the Visual Studio marketplace, which you can use to roll out releases of SQL databases on Azure as well as on-prem. In addition to that, you’ll find that there are plenty of open source third-party tasks that are available within the marketplace that allow you to do stuff on SQL– for example, take a backup of the SQL database, just run a random script, and maybe run an inline script or execute a stored procedure. But all that aside, there is out-of-box support as well.
So again, in this video, rather than– like we did in the previous video, rather than show this to you in Release Management, I’m going to continue building the pipeline that we’re working on within the team build. And then towards the end, we’ll take all of this and assemble it into a release pipeline with phases. So for now, we’ll focus on the task, which is taking the right task, putting in the right parameters to do the actual deployment of the application, web, and DB on this newly provisioned infrastructure. And in the future video, we’ll see how we can pivot that into Release Management.
So without further ado, what we’ll do is first look at the newly provisioned infrastructure, roll out the web app, roll out the SQL. So this is the project that we had from last time. We have the infrastructure project in there. And if we go across to Visual Studio Team Services, you would see that we have the same resource group that we had created, the Summit-sea resource group. It’s got the database. It’s got the web. It’s got an app inside and a hosting plan associated within the resource group. And if you click on the website and then you navigate across to the website, you’d see that it’s empty.
So while we have a newly provisioned website, it doesn’t have the application contents rolled out. And similarly, if we check the database, it’s pretty empty. It doesn’t have anything rolled out on it. So going back into this build pipeline that we have, I’ve added a couple of tasks in there. The first task that I’ve added is called the Azure App Service Deploy task. And you can find it by clicking Add Task and searching for Azure Web. And then it shows you Azure App Service Deploy. Now, the Azure App Service Deploy has multiple versions available. So I’m using the latest version here. And you can see that I’ve got a few nice options available.
So for example, I can deploy the slots. Now, if you’re not familiar with slots, Azure web apps expose multiple slots. And slots are really just tenants to the same website. So I could roll out my application on one of the tenants to that website, redirect some of my traffic to that tenant, see how the traffic is working out, if everything’s working fine in terms of the new release I’ve rolled out, and then that– make that tenant, i.e., the slot, the primary and take the secondary slot, which was previously production, and make that test and do a rollout of the application there.
And this allows me to roll out my release and test the release in production with some traffic to make sure nothing’s broken ahead of actually exposing it out to the entire traffic and rolling it out across multiple slots. So slots are really powerful. And we’ll go into a little bit more detail on slots, canary instances, A/B, red-green servers, as well as feature flags, when we look at continuous deployment in the next module. But for now, all we’re doing is we’re taking the release, the Deploy artefact that we had provisioned earlier on, and just specifying that look for the path .zip in the artefact. And that’s the Web Deploy artefact that we had provisioned.
Just to refresh your memory, if we go back into the build and we go back into the definition and if we open the definition and open one of the previous builds, you would see that with the build, we had this artefact that was generated. And this section at the top was the Web Deploy, which had the package and the config files associated with it. And then under the source, you had the DB, which had the DACPAC file. So we’re simply telling the task that the attached artefact has the web and the DB stuff that we wanted to deploy.
So going back into the build definition here, in this task, we’re just saying, look for .zip because we only have one ZIP file in there. But you could make it fully qualified by calling out the specific name of the file, as well, if you wanted to. In addition to that, this parameter, the WebApp, is something that we generated by running the script that we looked at, which queried the resource group, found all the resources in it, looked for the Microsoft.Web.sites, and then took that name and saved it as a variable.
We’re simply reusing that variable because we need to tell this task what is the app service name– i.e., this– where we want the contents of the website to be deployed. Now, again, we’re using variables, which means our processes full-fidelity. We can run it multiple times. It’s idempotent. It’s not going to start creating multiple instances of the website because we’re using the same website name as variable all across in the pipeline. Then that’s it, really. That’s it. And then in the next step, we’re going to deploy the database. And in the database, again, we specify the Azure endpoint where this needs to be deployed. And we need to specify the database name.
Now, again, the script that we had created which queries the resource group, gets the name of the resource, which is of type SQL Server, is what we’re using in this step. It’s just nicely passed across, formatted. And then we’re saying the database name is summitdb. This is something we could pass as a variable, as well, if we wanted to. We’re specifying the login for that user. And then instead of exposing the password here, we could actually convert this into a parameter as well. So I could say SqlDbPassword.
And then I can go back into the Variables section, Add, SqlDbPassword– sorry– SqlDbPassword– specify this value here, and decide to encrypt this value, which means it’s not going to be passed as a clear string. So let’s save this here.
So the builds just completed here. As you can see, this took about seven minutes to– seven-odd minutes to complete. And all the tasks are showing as green. So let’s click on the first one, which is Azure App Service Deploy. Let’s see what happened here. And as you can see, it successfully found the package. And then it used msdeploy, along with the package that we have here. We’ve got a bunch of stuff here– just explain that it’s unpackaged data and then just went through the hoops and deployed it. So if we click on the link here–
gives you a nice summary at the bottom, saying 86 new files added, zero deleted, and four updated. So as you’re doing incremental deployments, you can keep an eye out to see what changes are going in. So if we navigate back here, we see the app has successfully been deployed. If I go and refresh this, as well, we can see it’s been successfully deployed. And let’s look at the next one, the DACPAC file. We can see it found our package. It was able to connect to the SQL Server. It was able to initialize. It was able to deploy the Campaign, Campaign Detail table. It was able to– it deployed the constraints that we had.
So all in all, it’s managed to completely deploy the DACPAC. Now, if we want to check the database, we would actually have to go in into the Azure portal, click on the database, Set Server Firewall, add our client IP as an exception, save this.
Now that that’s saved, we can take the server name.
Let’s bring this back into Visual Studio, add a new server.
The server name needs to go in here. And let’s change this to SQL authentication.
There we are connected. And if I navigate in, look for the databases, we have the summitdb here. And if I look in the tables, we can see that our tables are deployed here, the Campaign and Campaign Detail. Now, if I go into the Campaign table and I say View Data–
excellent. So we can see that the data is available there as well. So in this video, we saw how easy it is to actually take your projects that you have in Visual Studio that you had written to provision the infrastructure that you had written to produce artefact outputs, like Web Deploy, like DACPAC files, and then tie that all nicely together using the out-of-box tasks that are available within Visual Studio Team Services to do a full-fidelity, idempotent deployment of the assets.
Being able to deploy the database is one thing. But being able to run the scripts and then have them updated is, I think, the full circle, which means if you’re making changes to your application which also involve database-specific changes, then you are including your DBA team to be part of the same workflow. And it’s when you break these silos that you can converge to deliver more value to your customers quicker. So join me in the next video, where we’ll cover another aspect of configuration management, which is, as we’re going to deploy into multiple environments, how do we make sure that the configuration sticks for that environment rather than the local development configuration.
And also, we’ll be looking at how we can now automate some of the functional test or smoke test that we have that we can use then to smoke test the deployment that we’re just rolling out to this test environment– plenty of exciting content lined up. See you in the next video. [SOFT MUSIC]
So far in this activity, you discovered the concept of release management, Release Management as a service in Visual Studio Team Services and how to create Release Management workflows.
In this video, we will build on the infrastructure that we provisioned with an Azure resource group template that we created within Visual Studio. Here, we will layer our application on top of our newly provisioned infrastructure.
Creating Automated Deployments with Release Manager
Before we get started, it is useful to look at the infrastructure that we provisioned. From within Visual Studio Team Services, you will see the resource group that we created. This resource group should have our database, the app insights and a hosting plan associated with it.
You will notice that the contents have not been rolled out to the website and the database is pretty empty.
To get started, from within the build pipeline, you can add a couple of tasks. The first task that you will add is the Azure App Service Deploy task. You will find this task by selecting Add Task and searching for Azure Web.
You can take the deploy artefact that we provisioned earlier on and specify that you are looking for the .zip part in the artefact.
You will notice the WebApp parameter that we generated by running a script, we queried the resource group and looked for the Microsoft.Web.sites resource and saved it as a variable.
Here, you will specify the Azure endpoint where the database needs to deploy to. We created a script that queries the resource group and obtains the type and the name of the resource.
Once you have indicated all the additional parameters, you can save your build. This may take some time, after which you can review the process.
Remember to engage with your peers – ask a question, leave a comment or share an experience. When you are ready to move on, click on Mark as complete and we will continue to our next step which is From Continuous Delivery to Continuous Deployment.
This article is from the online course:
Microsoft Future Ready: Continuous Integration Implementation
Created by
This article is from the free online
Microsoft Future Ready: Continuous Integration Implementation
Our purpose is to transform access to education.
We offer a diverse selection of courses from leading universities and cultural institutions from around the world. These are delivered one step at a time, and are accessible on mobile, tablet and desktop, so you can fit learning around your life.
We believe learning should be an enjoyable, social experience, so our courses offer the opportunity to discuss what you’re learning with others as you go, helping you make fresh discoveries and form new ideas.
You can unlock new opportunities with unlimited access to hundreds of online short courses for a year by subscribing to our Unlimited package. Build your knowledge with top universities and organisations.
Learn more about how FutureLearn is transforming access to education
