We have a requirement to update a text file during the release phase in VSTS depending on which environment the solution is being deployed too. I am a complete beginner to this.
I've looked at variables but I'm not clear on whether this will solve this particular problem.
There are many tasks that can update the file during the release, such as RegexReplace Build task (As rickjerrity mentioned), Replace Tokens etc…, you also can do it programming (e.g. PowerShell) during release.
Steps:
Add the environments with same name for each environment (Set Scope)
Using that variable in task.
Related
We have a release definition which delivers a bunch of asp.net core services along with an Angular app.
Most service are not updated very often so the question is how to compare an artifact version with already deployed into an environment and skip if the latest version had been deployed before?
We have multiple environments in the pipeline.
I dont think it is possible, at least natively, you can calculate file hashes and dont deploy if they match, another option would be using path triggers to filter when an app is build. for example, your directory structure looks like this:
root
|--app1
|--app2
etc
you can define path filters in your yaml build like this:
trigger:
paths:
include:
- app1/*
- sharedlibs/* (if you have them)
this way build will only trigger if there are any changes to files in those directories
You can add additional release environment to check current artifact version through PowerShell (e.g. Build.SourceVersion, check variables in release), then fail task if there was already successfully released.
For Staging environment, choose After environment option and select previous environment.
On the other hand, since you have mentioned most service are not updated very often, you could use 4c74356b41's suggestion to filter build, to only build and release the changes you want.
I've created a VSTS build with an Azure PowerShell script that works perfectly. The issue comes when I try to call the exact same script (exact same file in a git repo) from my VSTS release. When the script runs I get no errors but the environment variable, $Env:BUILD_SOURCESDIRECTORY, is empty. Like I've said before the VSTS build executes perfectly but I'm unable to run the exact same code in a VSTS release.
Your problem is that you are using a Build variable inside a Release. This just isn't going to work, it's empty because it simply doesn't exist in a release context.
Even if you could do this, I wouldn't suggest you do this. Your release should rely solely on artifacts, not build variables when the artifact was generated. You could certainly define this variable in your artifact, and access from the release, but I would highly suggest you not go down this path, as it's a really bad practice.
You didn't mention it, but if you stated why you think you need access to a build variable, perhaps we could help you find a better solution here.
Not all variables that are available in Build are available in Release. The Sources directory is available during the build. If you want to keep it available during Release, you should create an artefact in the Build, name it Sources. That way the artefact will be available in Release through its respective variables.
Overview of variables available in:
Release
Build
I have an ASP .Net MVC application with 4 different publishing profiles: dev, test, demo and prod.
These publising profiles are build using the same two steps: NuGet restore followed by an MSBuild. Then, they are deployed to lots of different servers: a few dev servers (one server dev per team), one test server, one demo server and several production servers.
msbuild /p:Configuration="$(Configuration)"
/p:PlatformTarget="any cpu"
/p:DeployOnBuild="True"
/p:DeployTarget="MsDeployPublish"
/p:MSDeployServiceURL="$(MSDeployServiceURL)"
/p:DeployIISAppPath="portal"
/p:CreatePackageOnPublish="False"
/p:MsDeployPublishMethod="WMSVC"
/p:AllowUntrustedCertificate="True"
/p:UserName="Deploy_User_For_TFS"
/p:Password="P#ssw0rd"
/p:AutoParameterizationWebConfigConnectionStrings=False
/p:ExcludeFilesFromDeployment="Cache"
Currently I have 4 TFS Build configurations (one for every publishing profile) and a file where I have all the possible values for MSDeployServiceURL parameter.
There are two issues with this approach:
When we had to add a new parameter AutoParameterizationWebConfigConnectionStrings we had to change it in 4 places instead of one.
We have to have a shared file as the source for the parameters. it is not easy to understand where which value should be copied and people often make mistakes.
So I have two questions:
Is there any way to have a one universal template where I can specify only my parameters Configuration and list of possible MSDeployServiceURLs and have everything else stay the same? Having such a template should fix problem #1.
Is there a way to define a drop-down like variable, where the value could not be typed in by the user, but should be selected from a pre-defined list of values?
Is there any way to have a one universal template where I can specify
only my parameters Configuration and list of possible
MSDeployServiceURLs and have everything else stay the same? Having
such a template should fix problem #1.
You could simplify such that the release configuration creates a templated publish profile. Then using TFS's release management, you could update the publish profile with the appropriate values. Based on your description, it seems like you are trying to combine both the compilation and the release.
For example, in TFS you could have one build (for example, MyApp-Release) that builds the code in the release configuration. As part of that process, it passes in placeholders for things like the deploy URL. For example, /p:MSDeployServiceURL="$(MSDeployServiceURL)" would be /p:MSDeployServiceURL="__MSDeployServiceURL__".
In the TFS release, you'd have a step that the replaces tokens (if you need one, you can use Colin's ALM Corner Custom Build Tasks) in the publish profile. The replace token task would then update the __MSDeployServiceURL__ with the value from an release environment variable with the same name (minus the underscores). So your release would have a dev, test, demo, and prod environment and for each environment, there would be a variable named MSDeployServerURL in each with a different value and a replace tokens step.
I have a Service Fabric project set up with CD in VSTS. The CD process have been set up from the CD wizard in visual studio. So far so good but when the release is made I'm not getting any value from the pre-defined variable called Build.DefinitionName that I use for naming the releases.
This is how my Release name is configured: $(Build.DefinitionName)-$(date:yyyyMM).$(rev:r)
If we look in the release log there is no value for the variables:
[BUILD_DEFINITIONNAME] --> []
[RELEASE_ARTIFACTS_{Primary artifact alias}*_DEFINITIONNAME] --> []
*This value is populated correctly.
And according to the docs of primary artifact variables the two variables above should be the same.
As a result of this my releases are named $(Build.DefinitionName)-201702.7
If I use Build.BuildNumber instead. I get the correct value.
How can I get the variables populated?
Update
When creating the Build and Release definitions manually the $(Build.DefinitionName) gets populated correctly on the Release side. But the problem seems to appear when you use the CD wizard from Visual Studio. I might be missing something but the settings of the Build Definition are identical. Or there is some funky stuff going on with the CD wizard.
The solution is to create the release definition manually on web access and set Continuous Deployment.
On the build number is passed from Build to a release, there is no out of the box way to pass more variables between build and release.
However I write a ser of build tasks to do this: https://marketplace.visualstudio.com/items?itemName=nkdagility.variablehydration
It consists of two tasks, the first saves the specified variables to a json file, which you should put in the build output.
The second restores the variables you want. Especially useful if you have multiple source build for your release.
We are using octopus to deploy our project. A bunch of steps which gets executed during the deployment. One of them is a powershell script and that powershell script is a work in progress.
However to test the script we have to perform a dummy check in or can create a new release in octopus after we change the build powershell script step, and it will pick up the build steps straight away and does not cache, else the script which gets executed is the previous version.
I do not know if this is caching or some other issue. I think this is some kind of issue with octopus or setting which I am missing.
Please help.
An important aspect of deployment automation is ensuring that deployments are repeated exactly each time they run.
When you create a release in Octopus Deploy, the artefacts, process, and variables are all "locked in" for that release. This means no matter what changes you make, for the lifetime of that release it will be performed identically every time.
If your deployment tool didn't do this, the same relase could work in your test environment, but then fail in the live environment because the deployment process changed in some way.
In effect, you release changes to the deployment process in the same way you release changes to the application itself.
This is why you need to create a new release in Octopus Deploy in order to see the changes you make.
This is both a blessing and a curse... On the one hand - your existing release scheduled for Production is protected from changes being made in lower environments. On the other hand - you are forced to recreate a release if you need to make a slight process change mid-cycle. This is arguable the correct approach since you would want to test any changes - but maybe not relevant if your changes can only be tested in higher environments (e.g maybe only Production is load balanced).
The software does allow to update Variables mid-cycle, but not Process Steps. I believe this feature is been requested for a future release.
http://help.octopusdeploy.com/discussions/questions/5130-how-to-update-a-single-variable-in-an-existing-release