I have a .Net 4.5 project (it will soon be upgraded to 4.6) that talks to a database. Right now I have different databases (dev test production) parameterized in my web.config file that looks like this
<add name="DevConnection" connectionString="blah...." />
<add name="TestConnection" connectionString="blah ... test" />
<add name="ProductionConnection" connectionString="blah... production" />
The way I switch this before I deploy Azure (PaaS or IaaS) is I change the following
public DBContext(): base("DevConnection") // this one is our azure Dev DB
{
}
in my DbContext file.
Is there a way I could parameterize that DevConnection on the right so when I queue up a build in Visual Studio Online aka VSTS or Visual Studio Team Services so it can switch the database to match the environment I am deploying to? Any insight on preferred ways to do this would be appreciated.
You can use Web.Config Transformation, refer to following links for detail:
http://blogs.msdn.com/b/webdev/archive/2009/05/04/web-deployment-web-config-transformation.aspx
Assuming you're using the new web based build system, you can build the .NET project to a WebDeploy package using the Visual Studio Build step and with a second Azure Web App Deployment step deploy the WebDeploy to Azure. Instead of having different connection strings you'll pass different parameters to the WebDeploy deployment step to set the connection string in the web.config accordingly.
You can also use the new release management, which is currently in preview, to deploy the web deploy to different environments.
You can create a single build and then use Release Management to deploy to different environments.
You can use the Tokenizer task to change the DB config string depending upon the environment you are deploying to. The task is not there in VSO by default and the instructions to upload the same are in the below link.
tokenization VSTS task (github repo)
Related
I'm new in VSTS and I'm in this case, I have a single solution built on Visual Studio 2015. It contains 7 or 8 projects that reference each others, I need only to build and release 3 project of them on Azure VM via Visual Studio Team Services so the question is what is the best approach to do this?
Clarification: the projects that I want to deploy are 2 aspnet web sites and a windows communication foundation library.
In my iis I have the following configuration:
Mysite (the root site with the following applications inside)
RPT (other web site)
WCF (wcf library)
This is my current VSTS build definition and with the following artifacts:
But I can only select one zip to deploy:
I do not know if this is the correct approach.
To deploy the three projects to Azure VM, you need to add different tasks in your release pipeline to deploy the three projects separately.
For now, you are using an IIS Web App Deploy task you deploy one project. Then you can add other task to deploy other two projects separately.
I am trying to set up one of my ASP.net projects for continuous integration with TFS. Amongst my requirements, I need to set up TFS so that each time there is a successful build with passing tests, the ASP.net code should be deployed to my development web server.
What I have done so far is I have set up a private agent behind my firewall (so that the agent has a "line of sight" to the development web server. I've set up a build that runs all unit tests, and I have the gated check-in setup up so that the build is rejected if the tests don't pass.
I can see that the build artifact is created by the agent, but I am stuck with trying to figure out how to actually deploy the artifact to the development web server.
I have my publish profiles in Visual Studio, but I'm guessing that those are useless in TFS.
You can refer to below link and follow the steps mentioned in the article to deploy the artifact to the web server:
End to End Walkthrough: Deploying Web Applications Using Team Build
and Release Management
Deploy to a Windows Virtual Machine
Visual Studio Team Services Release Management IIS Web Deployment
vnext
For the publish profiles, you can pass parameters into MSBuild during the building in TFS, eg : /p:DeployOnBuild=true;PublishProfile=MyProfile
Reference below threads to use the Publish Profiles:
TFS 2017 publish with PublishProfile
Build and Deploy a Web Application with TFS 2017 using Web Deploy Package
I am using VSTS Release management to deploy artifacts to IIS websites. I have several Web applications and web services to be deployed. So, i am trying to figure out what sort of tasks that best fits my situation.
I have created a build definition with Visual Studio Build Task for projects as this one:
which works fine but i need to add a task for copying the artifacts Under IIS Website Directory.
The other approach is to use IIS web deployment as a task in Release definition, so I created the build definition as:
However, it expects a Publish Profile (the build fails because it can't find it). I don't need to create a publish profile for each project in the application because this would be too much work.
Is there is a workaround for that or what is preferred approach for this?
You can update your build definition to generate a web deployment package and upload it to artifacts. And then in Release Management, add a task to run "projectname.deploy.cmd" in the deployment package to deploy it to your IIS server. Refer to this link for details: How to: Install a Deployment Package Using the deploy.cmd File Created by Visual Studio.
And you can also enable FTP Publishing on your IIS server and add a task in your release to publish the artifacts via FTP. You may need this task:
FTP Uploader.
My Continuous Delivery with TFS / VSTS – Server Configuration and Application Deployment with Release Management blog post (with reference to some previous posts) has all the details you need for deploying your artefacts to target nodes using Windows Machine File Copy tasks then use PowerShell on Target Machines tasks to get them in to correct locations and to do token replacement and anything else that's required.
I would recommend using PowerShell DSC so that IIS is properly configured before deployment but that's not required. Where possible for web apps I favour keeping things very simple by creating artefacts that contain all the web files that are needed for a particular folder and then just using plain xcopy for the deployment.
If you need more control you can also use my MSDeploy VSTS extension to deploy a MSDeploy package
https://marketplace.visualstudio.com/items?itemName=rschiefer.MSDeployAllTheThings
https://dotnetcatch.com/2016/04/20/msdeployallthethings-vststfs-extension-is-public/
I'm trying to use TFS 2015.1 on premise to build a CI pipeline for our dev & uat. I've created a vNext CI build, which builds fine. But when I want to add a deploy step for on prem IIS server, I only then see Azure Web Deployment options.
Ideally I wanted to add a step which uses the existing deploy (MS Deploy) profiles, which I'm able to use from VS2015 directly, using 'Publish'. However I see no option to do so.
How can I deploy the latest build to internal dev servers (not Azure)? I would like to use the MS Deploy option, unless there's a better way of doing it?
The fact that their is no option to starts to make me think there's probably a different way to accomplish it!
Thanks.
If you're able to upgrade to TFS 2015.2, web-based Release Management came out with it that works similarly to Build vNext with flexible and open-source tasks. You can also customize tasks.
Here's a link for IIS Web App Deployment from the vso-agent-task's GitHub repo where Microsoft stores updated versions of their tasks that you can download for web-based Build and Release Management.
I'll be publishing a blog about web-based RM with TFS 2015 Update 2 or VSTS on my website in the next few weeks. To give you an idea though, the starting point (for a web application) is a folder in your web project called WebDeploy (no significance - any name will do) that contains a PowerShell DSC script that configures the server, deploys the web files and then replaces any tokenised configs. To give you an idea see this post about how to use DSC to configure servers. (Only covers part of the final script though!) The next steps are:
In the build hub create a Website artifact - containing your web files and DSC script.
In the release hub for an environment use a Windows Machine File Copy task to deploy the artifact to a temp folder on the target node.
Then use a PowerShell on Target Machines task to execute the DSC script. After configuring the server the script copies the web files to their proper location, sorts out config using xReleaseManagement and cleans up the WebDeploy folder.
See this article for general details of the route I'm taking, but watch out as it has some errors eg the firewall instructions are incomplete (file and print sharing through the firewall needs to be enabled).
I can thoroughly recommend the PowerShell DSC route - I've had a few glitches but on the whole it feels very productive and the right way to be going.
I have a project that uses Entity Framework 6.x, ASP .NET WebApi 5.x. Data Access is in a secondary project inside the solution. I want to use VSTS (aka Visual Studio Online) to build and release it as a website to environments for integration/dev, qa, stage, and production. There are some great videos on Channel 9 that deal with the generic high-level description. (for example https://channel9.msdn.com/Series/DevOps-Release-Management and https://channel9.msdn.com/Series/DevOps-Fundamentals/Infrastructure-as-Code) There are all kinds of articles and videos about how to do migrations from inside Visual Studio including generating scripts.
Searching around the web I don't even find any older resources or concrete examples of continuous deployment with code first migrations. There must be examples and best practices for methods other than auto-migrations or SQL scripts.
I have configured a Web Deployment Package publish profile. I use it via the PublishProfile msbuild.exe directive. The package is added to the artifacts and then deployed by the Azure Web App Deployment task in each Release environment. However once this package is built, I don't know of a way of changing the connection string in the build package for each time it is released to an environment.
There is probably something I am overlooking, but how should environment specific migrations be done with via VSTS Release?
For Code First Migration, you can "Write App_Start code to run Migrations" or "Write Web.config transforms to configure the MigrateDatabaseToLatestVersion initializer to run", refer to this article for details: http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx
For the connection string transformation with profile, you need to add a web.config file for the publish profile and then enter the connection string in this web.config. Refer to this link for details: http://awaitwisdom.com/publish-profile-config-transform/
I hate to answer my own questions here but, ultimately my research took me to the conclusion I am posting at length here. In sort, Web.config and Parameters.xml require some custom scripting that will require you to maintain your own deployment automation. These routes will still require you to additionally create your resource groups or manage them manually.
To avoid these complications and cobbling tools and scripts together, the whole operation can be achieved with two JSON files. These JSON deployment templates allow you to create or update your resource group when your deployment runs. They also allow you to automate setting appsettings and connectionstrings that overwrite your Web.config values in the same manner as you can through the Azure Portal.
the steps: (1) Add the two JSON files to the project setting the name of you connection string on line 88 (2) Add a Azure Resource Group Deployment task to the Release environment. (3) Set Template (WebSite.json) and Template Parameters (WebSite.parameters.json) paths in the task. (4) Set Override Template parameters to -hostingPlanName "myHostingPlan" -webSiteName "myWebsiteName" -connectionString "the-actual-connection-string" (5) make sure you are using the same website name in your Azure App Deployment task.
This does depend on having your code first migrations run via App_Start or something similar. I took the first part of #Eddie's suggestion since App_Start is easy to deal with and doesn't seem to run too often.
As a bonus you can add environment variables for any of this configuration so you can clone the environment and then just change the variables. This ultimately makes your application or api connection string a Release variable.