To paraphrase this rather long question:
Why would you need more than 2 build configurations for their project when used in conjunction with service configurations ?
I have a cloud service that contains multiple websites which needs to be deployed onto a number of different Azure platforms, one for Test, one for UAT, and one for Live.
Each environment needs a different host header defined for the website it deploys e.g. test.myportal.com, test.myservice.com, uat.myportal.com, uat.myservice.com, live.myportal.com and live.myservice.com.
This means I need to define a ServiceDefinition for each environment, fine so far.
In previous related questions I've seen (Azure: Is there any way to deploy different instance sizes for test/production, Azure connection string best practices (step 4, and using $(Configuration) instead of $(TargetProfile) in the .ccproj file), people have mentioned that you will need X configurations (meaning build configurations). This doesn't make sense to me, as I only need two build configurations (Debug and Release) for the way that the code is built, rather than how the service is configured. Rather, what I need are three service configurations.
My question is, am I right in thinking that a build configuration should only be used for how the code is built and that people who create multiple different build configurations for service configuration are wrong? (That's not the best word to use, I admit)
To further explain how I'm implementing a solution around this, I continue below:
I'm configuring my CI build server for MSBuild to take an additional parameter, TargetProfile, alongside Configuration.
The MSBuild commands for my environments look like this:
For Test:
msbuild mySolution.sln /p:TargetProfile=Test /p:Configuration=Debug
For UAT
msbuild mySolution.sln /p:TargetProfile=UAT /p:Configuration=Debug
For Live
msbuild mySolution.sln /p:TargetProfile=Live /p:Configuration=Release
For my cloud service, I use three ServiceDefinition.csdef files, one for each environment: ServiceDefinition.Test.csdef ServiceDefinition.UAT.csdef ServiceDefinition.Live.csdef. These are kept in a '/config/' folder.
In my cloud server ccproj file I only have two Configurations, Debug and Release, with a task in BeforeBuild :
<Target Name="BeforeBuild">
<Copy SourceFiles="configs\ServiceDefinition.$(TargetProfile).csdef" DestinationFolder="$(OutputPath)" />
<Move SourceFiles="$(OutputPath)ServiceDefinition.$(TargetProfile).csdef" DestinationFiles="$(OutputPath)ServiceDefinition.csdef" />
</Target>
This then ensures that I only ever need two build configurations, but can have as many service configurations as I like, just by changing the TargetProfile parameter that I pass into MSBuild.
To reprise my question:
Am I right in thinking that a build configuration should only be used for how the code is built, and that people who create multiple different build configurations for service configuration are wrong ?
One possible use case of different build configurations might be when a service needs to be deployed to multiple product platforms for different customers with different feature sets. In such a scenario, it might make sense for the build process to customize the individual feature sets (e.g. via the use of C# Preprocessor Directives) for performance and security reasons.
Related
I have a console application where I need some ideas on how to build/release the config part of the application. When running locally in VS the config file is called app.config. After a build the file changes to .exe.config. We are using XDT transformation for building the config file to the different enviroment. But what would be the smartest way to ensure the naming convension is correct when release the build version to a server?
Seems you want to use TFS Build and deploy to multiple environments via Release Management.
For handling configuration in Release Management, there are two techniques generally used Config Per Environment and Tokenization.
If you prefer a clean separation between build and deploy. To achieve that, recommend tokenizing configuration.
More details please take a look at this wonderful blog: Config Per Environment vs Tokenization in Release Management
Environment specific application settings values configured in the app.config are tokenized. Above blog's method essentially inserts tokens into setting values during the build process. When deployed the tokens are replaced with matching Release definition configuration values.
Besides, for an example of a separate build and release solution, you could also take a look at this blog: Using web.config transforms and Release Manager – TFS 2017/Team Services edition (similar to app.config)
I am working on a website that will be deployed to various environments - Dev, UAT and Production - and each of them has different config settings defined through the use of config files.
The deployment process consists of two steps:
Publish the latest build output
Copy and replace the default config files with the one specific to the environment were the deployment is being done (these files are currently under source control)
I am trying to automate the deployment process using VSTS and Azure App Services but I couldn't find any task or option that would let me copy files into an App Service.
What is it the best way to implement this deployment process?
You can make this much easier on yourself by using config transforms for your web.config file.
Basically, make sure that you've defined a Build Configuration for each environment. Debug and Release are defined out of the box for Visual Studio MVC projects. You can add as many configurations as you want, such as a UAT configuration.
Once you have your configurations defined, make sure there's web.[your build config].config file located beneath your web.config in the Visual Studio solution explorer. Within each of these build configuration specific transform files, you can override settings as needed.
To close the loop, you can specify a build configuration to target when creating a build in VSTS. This will automatically execute the transform for the build configuration you've selected.
More details on build configs and web.config transforms here.
Alternatively, you could specify your app settings and connection strings directly in the Application Settings of your Azure Web App. These override anything in your deployed web.config file. What I like about this approach is that you don't have to expose sensitive information like connection strings to other developers on your team, and it removes the minor complexity of web.config transforms.
Kudu api give you the ability to upload and download files from azure web app with overwrite
The git:
https://github.com/projectkudu/kudu/wiki/REST-API
Not sure if vsts have this ability.
I recently did what you describe with Jenkins . Now I'm trying to integrate Jenkins to vsts
Hope it give you an answer
We are using Team Services to maintain our web projects and Azure for hosting. At now, there are several Web Roles (asp mvc) and Worker Roles which is being hosted as Cloud Services. We are going to setup Continuous Integration and Delivery for them.
As you know, Team Services Build Definitions suggest to use Azure Cloud Service Template for building and Azure Cloud Service Deployment Task to deploy. We’ve tried it for single cloud service and it works.
In our case, there are web project (web role) and scheduler (worker role) as separate Cloud Services and they should be deployed simultaneously (in sequence), let it be DEV environment. But we have much more environments: dev, qa, ta, demo, preview, production, etc. Furthermore, each of them has slightly different web.config, ServiceDefinition.csdef and ServiceConfiguration.cscfg. And it became much more complicated task than just deploy one Cloud Service.
Questions are:
Should we build dozens of Cloud Service pachages (artifacts) and later decide which of them deploy or not? Could you suggest how to do it in a proper way? (in most cases it will be only Dev environment and we will waste time and resources for building other artifacts).
Will it be better to build one common artifact and later replace all configurations for specific environment? (It’s more complicated task because Cloud Service package zipped on several occasions with preconfigured ServiceDefinition and ServiceConfiguration)
What is the best way to replace configuration tokens (web.config, serviceconfiguration, etc) in Deployment mode, or it should be done while projects is being built?
I would be grateful if you suggest any best practices.
For azure cloud project, it’s better to apply changes to the project per to the environment before build, so you can build the project during the release process.
Regarding to deploy to corresponding environment, you can configure artifact filter with build tag.
For example:
Add a file (e.g. json, xml or txt) to project that used to determine which environments the release should deploy
Add a PowerShell task to build definition to read the data from that file (step1) and add build tag(s) through logging command (Write-Host "##vso[build.addbuildtag]build tag")
Add Publish Build Artifacts task to upload the source files
Create a release definition and link artifacts and add multiple environments
Configure Pre-deployment conditions for each environment: Enable Artifact filters=>Select artifact=>Specify build tags
Add tasks and variables (e.g. visual studio build) for each environment to deploy to corresponding environments.
On the other hand, regarding replace value, there are many ways, such as Replace Tokens, XDT Transform
Am very new this kind of S/W development industry and since am here as system engineer, my task is to implement a Build and Release management system using Jenkins. So, far am able to install, configure and even build the war files for my java proj using maven after checking out the sourcecode from my svn. Now the actual task it to build mutliple war file for the same proj for my different environment like UAT, Staging and Prod. I dont want to create multiple jobs, however I would like to use the multi-configuration option to achieve this. So, can anyone please help me in doing this?
Thanks,
Sree
I strongly advise against building environment specific release binaries. Instead address what it is that makes one environment different from another. Generally it is configuration held in property files recording information like:
Database URLs and credentials
System sizing information
..
Baking this into the release makes your software very inflexible. For example why should you have to rebuild your software everytime the database password is changed?
The solution is the use of standards like JNDI. In tomcat you can use context files to set datasources and other variables.
So, here is the deal. In web app project settings I configured a deployment package which includes all content files along with IIS settings for the site & app pool. Now, when i go to Team Build build config, I use the following arguments to deploy the site.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=WMSVC
/p:MSDeployServiceUrl=https://<servername>:8172/MsDeploy.axd
/p:AllowUntrustedCertificate=True
/p:DeployIisAppPath="mysite.com"
/p:UserName=<domain>\<user>
/p:Password=<password>
While this actually works, the deployment will fail if "mysite.com" site doesn't exist on the destination server or if the app pool isn't set up correctly (i.e. ASP.NET version mismatch). So i find myself creating this stuff manually before i can deploy anything from Team Build. Is there a way to automate this? Am i missing some kind of argument switch? I guess another way to phrase this question, is why do i have to set all this up when the package includes all of IIS settings and should just deploy.
Thanks for any help/explanation.
EDIT:
I'm not entirely sure if this is true, but i believe i will not be able to do create site/app pool. From my understanding of things, Team Build uses msbuild to talk to msdeploy and that link is very limited in what it can do. So, I may be looking at changing the build workflow template to execute the command line to deploy the package (?).
Check out the TechNet documentation on the iisApp provider at
http://technet.microsoft.com/en-us/library/dd569054(WS.10).aspx. Of the four parameters, these are the ones you'd probably be interested in:
managedRuntimeVersion
skipAppCreation