We have built a small MVC4 application using Azure Cloud Services. It has been deployed through Visual Studio. Now we are going add a test environment where the application should be tested, before being deployed into production.
I would like to have our CI server to build, test and create a deployable package, This package could then be deployed to any environment, providing correct configurations.
But I have not found a convenient way to do this. It is easy to build a package for a specific environment, with configuration transformations for .config and .cscfg files.
Is having the CI server to build a separate package for each environment the way to go, or have I missed something?
There are ways described how the web.config could be modified when the WebRole is starting, but this feels a bit hacky, and not the way the guys at Microsoft intended when creating Cloud Services.
Using the CI server to deploy the specific configuration has been the easiest in my experience. I think using the Visual Studio "Build" section in Team Explorer is what your looking for. We use Team Foundation Service as our Continuous Integration and Continuous Delivery server. In Visual Studio we've created Production and Testing build configurations. In the Build tab we've created a Continuous Integration Build which will kick off unit tests on every checkin, and a Continuous Delivery Build That will deploy newly tested checked in code on a regular schedule. These Build Events can be set to use a specific (Production/Testing) build configuration.
Related
I have set up Azure continuous deployment from a branch in my Visual Studio Team Services GIT Repository. Everything is working fine however I would like to run a few gulp tasks before the actual deployment takes place. Is there a way how I can do this?
Azure provides continuous deployment out of the box through the use of several sources of your code. What you will need will be more in the side of continuous integration, running tasks and flows to build the code.
There are many ways and tools of doing continuous integration, nevertheless the most compatible to do this in Azure would be within the build and release parts of Visual Studio Team Services.
Within your Azure subscription you can setup this following the next steps(it seems you have already setup your code in Visual Studio team services, then you can skip to step 3):
Creating a VSTS project
Putting your code in a Git Repo inside VSTS
Creating a Build definition
Adding your tasks from the Catalog
Adding and configuring your Gulp Tasks
Deploying the build to Azure
I want to fully automate the deployment of a web application using VSTS. I have a sample azure application and I want to create a build definition on it that contains building the solution, running unit tests, and deploying it over azure on IIS as its build steps. I am new to VSTS, I am finding it hard to automate the deployment using VSTS. Seeking some help on how to create the above build definition. Any slightest guidance will be helpful.
Madhur,
You will find step by step up to date examples on the Visual Studio website:
Build and deploy your ASP.NET 4 code to an Azure web app
Deploy ASP.NET apps to Azure web apps
First create a build definition to test and package you web app.
Second get familiar with release definition to deploy it on Azure. Or if you just want to do it in one place you can have everything in your build definition, it's up to you.
Also when creating a build or release definition on VSTS, the templates offered are very useful, everything is done so you juste have to feel the gaps. I advise you to take a look at it.
Ive written up a walkthrough of this process at my blog site, its for an asp.net core app but the principal is the same for a normal .net framework one, in fact its even easier because you just choose the Visual Studio Build template when creating the build definition. My walkthrough also takes you through how to deploy the Azure resources you need to host the website - its good practise to use infrastructure as code for these, and maintain that code in the same way you treat source code, with CI and CD processes.
I have a Visual Studio 2013 solution with 3 cloud service projects (1 Web Role, 2 Worker Roles) and a set of nUnit tests hosted in Visual Studio Online.
Through Azure portal, I've setup a continuous integration build that builds and deploys my solution on checkin. Azure, however asked me for a single Cloud Service to deploy solution into (although my project contains 3 of them) and obviously, the build only deploys one of the cloud projects (presumably the first one it finds). How can I make it deploy all three?
I'd rather not create three different builds.
From my experience, you cannot deploy all of your azure projects within your solution to azure at the same time using the VSO CI builds. If you look at your CI build definition under process you'll see that you can only specify one cloud service name to deploy to. We ended up having to create one solution, with one azure project, and one CI build per cloud service. We use the staging environments as a temporary deployment destination until all of our services are built/deployed, then swap them all at the same time to achieve a somewhat seamless/instant update.
Hope this helps.
I was able to get this to work with the new VSO VBuild Next System in TFS 2015.
You are able to build a specific *.ccproj cloud service project and from there use a specific task to publish to azure.
This allows me to have multiple cloud services and multiple web roles in the same solution.
You should also be able to build multiple cloud service projects and setup multiple publish tasks, all from the same build definition.
From MS...
We've built a brand new scriptable build system that's web-based and
cross-platform. We believe all new and most existing customers should
use it instead of the XAML build system.
More info:
https://msdn.microsoft.com/Library/vs/alm/Build/overview
Here is a view of my build tasks..
Currently our developers deploy our Mobile Service (.Net backend) from Visual Studio 2013 using the Publish Wizard. Occasionally this means that a developer deploys something that either wasn't committed at all or wan't pushed to the origin source control repository. We are already using Visual Studio Online Build servers to do Continuous Integration from the origin server so it would make sense to use the files it builds to do the deployment to remove this risk.
Currently the only way I can see of doing this is to do a "download drop as zip" from the Visual Studio Online build portal and then do a FTP style deployment. This means I lose the web deploy features of only uploading the changes.
I noticed there is a different build template called GitContinousDeploymentTemplate which allows you to specify a Windows Azure Deployment Environment, but this seems to only be applicable for traditional Cloud Services or Web sites.
If anyone knows a good way of doing this any help would be much appreciated.
Cheers
F
From here
Found a solution.
In the build definition's MSBuild arguments, add the following:
/p:DeployOnBuild=true /p:PublishProfile="{publish name}"
/p:AllowUntrustedCertificate=true /p:VisualStudioVersion=12.0
/p:UserName={username} /p:Password={pw}
You can obtain the value from the publishing profile that can be downloaded from the
Mobile Service dashboard on Azure managament portal.
Under Deployment, add the path to pubxml file in source control under "Path to Deployment Settings". Note: add an extra backslash at
the end of the path to escape the last "\".
One problem with this solution is that deployment happens regardless
of your tests outcome, but that could possibly be remedied by
modifying the build template. We used the
GitContinuousDeploymentTemplate template in our case.
Visual Studio 2013 has a publish wizard for Cloud Service projects that packages and deploys a cloud service based on settings persisted in a .azurePubxml file.
I'm setting up automation of this process on a CI server, and want to leverage this functionality within MSBuild, but I'm unsure if it's even possible.
I have found a lot of articles that talk about shelling out to a PowerShell script and using a custom MSBuild target file to do the deploy, but that seems like a duplication of information that I'd rather not delve into.
Given that I have the Azure subscription credentials installed on the build machine, VS 2013, and Azure SDK 2.2, can I invoke the same mechanism that VS 2013 uses in the publish wizard to package and deploy my cloud service?
Currently, using MSBuild with the publish target, I can package the service into a .cspkg file, but I cannot figure out how to trigger to package/deploy based on a profile (.azurePubxml file) that defines the VS build config, and all of the Azure settings.
So, as you pointed out, the default targets will only give you a package. From there, Visual Studio is publishing things using their own infrastructure. Publishing the build from a CI server is considered something external to actual build process and rather something that is part of the deployment process.
If your CI technology has support for PowerShell then it's as easy as automating the Windows Azure PowerShell cmdlets to do your bidding. There's a nicely detailed article on how you might do this with Team Builds in TFS here on MSDN.