I want to apply web.config transformations with Octopus Deploy, but only on the production environment.
I don't want to create separate configs for all of our other environments.
At the moment i'm using this following custom expression but it doesn't apply the transformation
Are you specifically trying to change key/value pairs within the web.config file of your project? XML transforms are a different function altogether. Read the documentation here: http://docs.octopusdeploy.com/display/OD/Configuration+files. That documentation will refer as well to MS documentation on transforms: http://msdn.microsoft.com/en-us/library/dd465326.aspx
Having said that, it looks like you mean to say you want to change the value of configuration variables within Octopus. Octopus can definitely do that; especially when targeting a specific environment. Go to the "Variables" tab in your project. Within the variable tab, the "Name" column refers to the value you want to change in your web.config or app.config. This is the EXACT name as it appears in the file so you don't have to change anything directly in the file to match.
The value is of course the value to appear. Then the Variable Scope column will allow you to specify the environment, server, roles and even step within the process (mine doesn't appear as this is a blank project).
Edit:
Read this documentation from Octopus Deploy on config files (and further down is web transformations).
It looks like your custom expression for the transform are incorrect if you're trying to remove the debug mode flag. Judging by the expression you input, it will render as "TrueProduction.Production" which really doesn't describe any type of transformation. You should probably try this instead:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>
</configuration>
Make sure you have your production Web config file as: Web.Production.config if you only want to apply it for Production. Make sure that Web..Config matches that environment name in Octopus. Again, it's in the documentation on the Octopus Deploy site.
What you have to do is create a Web.Production.config transformation file where "Production" is the name of your production environment. Once you enable the XML transformation within your Octopus Deploy task, Octopus will apply the production transformation only when it's deploying to be production environment. This might be also true if you create a Web.Release.config transformation file instead of specific environment file but I am not sure.
Related
is there a way in the TeamCity to have application config files with production passwords stored in the TeamCity?
During build/deployment these files will be used for different environments.
For example in the project repository you have app.config file which is filled with Development env secrets. And you don't want to store production envs secrets in the repository.
Need exact file because it's not only a single values which could be covered with Configuration Parameters, it could be big XML pieces. So better to have a whole app.config file somewhere in the TeamCity configured which I can use to publish to production env.
Thanks in advance
As I know in Team city administration you can configure each build configuration as administrator. And for build configuration, you can find the parameters section where you can add parameters as secret values. These values would be available during the build process but they would not be logged. Hope it helps you.
I have web application which contain multiple property files like test1.prop, test2.prop... and so on.
I am writing Ansible playbook to deploy my code but I was stuck when it comes to property file changes.
Right now the support team changes it manually by referring the release notes.
What i want to achieve is this -
When the release comes, it needs to be deployed to different environments like dev, preprod, prod etc.
The values in the property file could be different depends on the environment like env.baseurl= {{env_baseurl}}. I was thinking of using Jinja templates for this.
I need to loop through the currently deployed property files, check if they are same or if any file any difference with the current release and change it accordingly.
How do i make a script or playbook which is generic and can be used to deploy on each environment.
Please let me know if someone can help.
I'm using msdeploy on the command-line to deploy a windows service using the sync verb against dirPath source and destination providers. So far so good.
My project's build assets have per-environment config files, and during deploy to a particular environment I want to rename the targeted environment's config file to the default config file name using a replace rule, but no matter how I engineer my replace rule nothing seems to get me the results I want. I've tried with a number of different configurations of the rule with no luck but the one that seems the most logical is this one:
-replace:objectName=filePath,scopeAttributeName=path,scopeAttributeValue=Service\.Dev\.exe\.config,match=Service\.Dev\.exe\.config,replace=Service.exe.config
If I deploy without the replace rule both Service.Dev.exe.config and Service.exe.config are deployed with the expected respective content. Once I add the replace rule above I get just Service.exe.config and it's got the content of that file from the source, not the content of Service.Dev.exe.config as I am hoping for. If I swap the specifications of the match and replace components (and change regexp <-> plain text accordingly) to arrive at:
-replace:objectName=filePath,scopeAttributeName=path,scopeAttributeValue=Service\.Dev\.exe\.config,match=Service\.exe\.config,replace=Service.Dev.exe.config
I just get Service.Dev.exe.config with the content of Service.exe.config and no Service.exe.config in the destination.
I'm sure I'm missing something obvious, but what is it?
This doesn't directly answer your question but I think its a better solution to your root problem.
The real issue here is config management for different environments. Many developers create different configs for each environment like you do. This approach requires a lot of duplication across your different config files which can easily get out of sync.
The best approach I've found for managing configuration across different environments is WebDeploy Parameterization. It is similar to config transforms in that you have a single base config file that is tweaked, so there is far less duplication. Parameterization however is preferred because it applies the changes at deploy time instead of build time. We use this for 50+ applications with great success.
Here is a blog post with more details - http://www.dotnetcatch.com/2014/09/08/parameterizationpreview-visual-studio-extension/
The match and replace should swap
match=Service.Dev.exe.config,replace=Service\.exe\.config
I have an octopus deployment that needs to go to a load balanced environment But there are small changes in the config between the two servers.
So, in summary:
It deploys to the same environment (PreProd)
It gets deployed to two different servers linked to that environment
There are small changes between the two web.config files between the two servers.
I already have a web.preprod.config that gets transformed into web.config. Does it mean I need to create more config files, ie. web.server1.preprod.config and web.server2.preprod.config or is there another cleaner way of doing it? It is a whole section that is different so not just an appSetting.
A solution that has worked well in similar scenarios for me in the past (with OctopusDeploy specifically), is to use the web.{environment}.config transforms to get the correct config structure in place, but to use variable substitution and define placeholders in the transform file to keep the run-time environment-specific definitions in Octopus. Quite how you break down the substitution syntax is really dependent on your config, but you can use the machine-scoping features of Octopus variables to control the actual values injected.
This scenario is a good example of where web.config transforms start to blur the edges of configuration management; environment-specific config is really the domain of Octopus (or, more specifically, a centralised configuration store), but the solution proposed here is taking it out of Octopus and back into the source repository, which is one of the problems Octopus is actually designed to solve.
For example; what if you introduced a 3rd node in your pre-prod load balancer? This demands a code change, build, version bump and package, which can be completely avoided given the above.
The general approach to problems like this is, indeed, to create a web.server*.preprod.config, or local.config. I'd suggest looking at what exactly is different in the config, and why. Try to find things that you can merge. For instance:
If one difference is the difference in drive letter, and your config contains these entries:
C:/a/b/c.txt
C:/a/b/d.txt
try splitting those entries into
drive=C
drive:/a/b/c.txt
In that case you only have to change drive=C to drive=D to make two entries work.
We're testing Octopus Deploy 2.0 (OD) to deploy web services, windows services and citrix applications.
QUICK QUESTION:
When using config transformation, can parameters be used to indicate which config file should be used for the transformations?
MORE DETAIL:
When setting up for config transformations, we would like to have files named
MyApp.DEV_US.config
MyApp.DEV_CANADA.config
MyApp.DEV_AUSTRALIA.config
and so on for TEST, STAGE and PRODUCTION
Our deployments to DEV, for example, always include deployments to all regions. So we would prefer if OD environments were DEV, TEST, STAGE and PRODUCTION. Then in each deployment, we have multiple steps that deploy to each region.
However, OD config transformations only look for OD Environments when looking for which config files to use as part of the transformation. It seems OD would require us to bring each region up to the environment level, which from our POV is not ideal and would clutter the dashboard.
Can we pass parameters into the config transformation process such that we can indicate which file to use for the transform?
I believe you can achieve what you are after with the following, but it will require multiple steps in the process.
Create a step called Deploy to Dev - US and a step called Deploy to Dev - Canada
Now define a variable called CountrySpecificConfigFiles and you can scope it to the required step (and environment etc)
In the Configuration transformations section for each Steps, choose the variable defined in the step above
You could abstract this further by naming your steps DEV_US and DEV_CANADA and define just the one variable value as Web.#{Octopus.Task.Name}.config without any scope to steps, or by removing the variable and doing it inline in the Additional Transforms field.