On a regular base, we do some changes (modify or add) on our web application config file. Every time someone adds a new config line, he has to tell the team that he was adding a new config part to the global config. We have a scaffolding config under version control. Is there a smart way to merge the new config template with your existing config file? Does somebody know a tool to automating this process? We have also an testing and staging server, where this changes also have to be pushed on automatically (or raise a trigger if some manual changes are needed).
Related
we created a Terraform template which we will deploy in future many dozen times in different workspaces. Each workspace will have a separate configuration file.
Now we would like to automate this procedure and think about keeping the configuration files in a Git Repo.
Has anyone a best practise how to store the configuration files in a Git Repo and trigger a CICD workflow (Azure DevOps)?
In general we only would like to apply changes for workspaces that have a changed configuration.
The terraform plan and apply command have an option for you to pass in the tfvars file you want to use. So something like this:
terraform apply --var-file=workspace.tfvars
So in the pipeline you would grab your terrafom template artifacts and your config files. I would then set a TF_WORKSPACE variable to force your workspace and I would also make your tfvars files match the workspace name so you can re use the variable in your apply command. This would force your workspace and configuration file to match.
To trigger this when those files have changed would require a path trigger that would trigger on those changes.
I don't see any harm in running the Terraform every time regardless if changes occur. The worse possible outcome would be that someone made a change that isn't in Terraform and it gets undone.
In the product that I work on, there are many configuration tables. I need to find a way to track configuration changes (hopefully with some kind of version/changeset number), deploy the configuration changes to other environments using the changeset number and if needed rollback particular configuration based on changeset number.
I am wondering how can I do that?
One solution that I think could work is to write a script(s) to take all the configurations from all the config tables and create Json file(s). I can then check-in that file(s) to tfs or github to maintain versioning and write another script(s) to load that configuration file(s) in any environment.
I'm using Visual Studio Team Services and I'm trying to set up Release Management to allow automated deployments for our Azure Web App to multiple environments. I would like the same source to be deployed to each environment, but with modified configuration settings.
I was hoping that I could create a single Build for my application, and then modify the configuration at deployment time for each environment. I'm aware that this can be done for appSettings and connectionStrings (either through Tokenization, or even managing those settings via the Azure portal), but I'd like to be able to make more general changes to the web.config file. For example, I want to be able to:
Update 'simple' settings such as appSettings/connectionStrings
Update multiple attributes on elements (like httpErrors)
Insert or rewrite sections of the config file itself (for example to add IIS rewrite rules, or to remove unwanted HTTP handlers for production)
Currently we achieve this by using config file transformations and separate publish profiles for each environment (manual deployment). I can't see a way to re-use this if I want a single release pipeline.
I'm hoping someone can help point me in the right direction. I'm also happy to accept alternative solutions - ultimately I just want to be able to deploy the same source (e.g. from the same commit in source control) to multiple environments, with different configuration, while keeping some kind of flow from dev, to test, to eventually production.
You can use Tokenization Task to update the files base on the environment variables.
More similar extensions: Replace Tokens and Colin's ALM Corner Build & Release Tools.
I am using mercurial for website development. I "think" I'm using it correctly.
I develop on my development machine, commit fairly regularly. I will somewhat regularly push my commits to my hosted site-dev repository.
If things are set up how I want them for the live site, I push from my dev machine to the hosted site-live repository. Then I pull down from that repository onto the live server.
However, there are some changes that need to be made (changing directories from localhost to www.example.com, changing the DB connection stuff, etc.).
What I did was made these changes on my live machine, then pushed them back up to the site-live repository. I don't know why I did that, really, but at least there's a changeset sitting there with the necessary config changes.
What I don't know how to do is manage this process. I'm a little lost beyond committing, pushing and pulling with hg. I'm a single developer and haven't even done a merge yet.
Is there some way to keep that particular changeset identified, and just apply it, hopefully even BEFORE I pull from the repo down to the live server?
I think you can tell from my question that I'm in a little over my head with hg and workflow at the moment ;)
This is my understanding:
What essentially you are trying to do is have a development, staging and deployment environment. You do your development using 'development' repository, test it on a staging environment and then once satisfied, pull those changes into deployment repository.
And when you pull from staging to deployment, you need to change your environment / configuration data.
My take is you should not be changing the configuration at all.
You should have configuration files such that you have a
basic configuration file
basic.conf
Environment specific overrides
basic.dev.conf, basic.staging.conf and basic. deployment.conf
Use environment variable:
The overrides to the basic configuration data should be defined via an environment
specific variable : APP_ENV : dev or staging or deploy
This way you should be able to override the configuration based on the environment without changing the configuration information.
It is not a good idea to rely on making changes to config files each time you pull your code from development to staging to deployment.
I would keep the live server outside the version control. Meaning that I would have a small "install" script that pulls updates from the repository, removes any unnecessary development files, and applies the correct configuration files. Both development and production configuration files should be in version control.
Currently I am using a shared database model for our development. I know, it's better to use local development databases to do database versioning the right way without one developer breaking everyone else's code. So that's what I'm trying to get to. I have a question about the web.config file though. How do I ensure that once every dev has his own local development database, he doesn't have to manually change the DB connection string every time he gets an update from source control? What's the best way to do this?
For example, say Johnny Dev commits his web.config that holds a connection string like this:
server=JohnnysBox;database=JohnnyAppDev1;
So now Susie Dev gets an update and she has to change her connection string to this:
server=SUE;database=development;
So now Susie and Johnny keep committing their own connection strings to the web.config file, and every time they get an update, they have to change the connection strings in all applications.
What's the best way to handle this situation so that devs don't mess up each others' connection string settings, but can push other kinds of config file changes to all the other devs when necessary (like a new app setting)?
It's only a partial solution, but you could have all the developers create an alias for their own SQL server using cliconfg.
Then the web.config in source control will have eg:
server=LocalServerAlias;database=development
For configuration or settings files, what you need to version is:
a template files (server=#USER_NAME#;database=#DATABASE_NAME#;)
one or several value files
one script able to replace the variables by the right values
What we do here is to never commit the web.config file to source control. Instead, we commit a web.config.sample file, and each developer merges changes in that file into their own personal web.config file. It's each developer's responsibility to handle those merges.
The way I deal with this is to just not check in developer-specific changes to config files.
When a config change needs to be checked in, I start from a 'clean' config file and make the needed changes, then check in. When everyone else does a get latest, they can merge these changes into their local versions.
The solution we came up with at my office was that we specifically exclude the web.config from version control, but only in the www folder. This allows developers to make whatever changes they need locally.
In a separate folder, we have a "master" copy of the web.config which is version controlled. As new sections, keys, etc. are added, it's the developer's responsibility to update the master copy.
You can create multiple Web.config files depending on the environment the application is running in. Using the transformation syntax you can modify the main Web.config to include or comply with your own local settings.
http://msdn.microsoft.com/en-us/library/dd465326(VS.100).aspx
Afterwards, exclude this custom Web.xxx.config from your repository.
We branch the web.config. So, i've got one called Mattweb.config and I can change it at will, and it replaces the web.config ON MY LOCAL MACHINE ONLY with the contents of Mattweb.config. It's requires no intervention by me.
We also branch the "real" web.config, so that I can compare with my own local version to see if any appsettings were added or any other types of changes. Then I just update my Mattweb.config file and all is well again.
Use (local) as the sql server name and it always refers to the local server. This should be the default value in the web.config you check into source control.
For production "installs", your installer should ask the user if they want to use a remote sql server and if so, update the web.config files as part of the install process.