In Node.js, I want to set config property value based on platform (dev, staging, qa, production) it will get deployed.
So for example for dev and staging environment, I want to set value '234'
And for prod, i want to set value '456'.
for deployment, i am using VSTS.
Shall I make the use of deployment variables?
For setting config property based, please take a look at this question: Node.js setting up environment specific configs to be used with everyauth
In VSTS Release, you could use environment scoped value per environment.
Share values across all of the tasks within one specific environment
by using environment variables. Use an environment-level variable for
values that vary from environment to environment (and are the same for
all the tasks in an environment). You define and manage these
variables in the Variables tab of an environment in a release
pipeline.
Source Link: Custom variables
If you want to change values, suggest you to use Replace Tokens task Visual Studio Team Services Build and Release extension that replace tokens in files with variable values.
Related
In Circle CI, context can allow me to set different values for same variables.
For example, I set two environments, such as dev and prod, in each of them, I set several variables
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION
Since my environments are in different aws accounts, I can provide the different values to them.
Second, I can set permission that developers can only access dev context, support team can only access prod context.
But I don't get the same feature in Gitlab CI.
In one of their document, it mentions Group, but after I check, it doesn't work as expect at all.
https://docs.gitlab.com/ee/ci/migration/circleci.html#contexts-and-variables
Contexts and variables
CircleCI provides Contexts to securely pass environment variables across project pipelines. In GitLab, a Group can be created to assemble related projects together. At the group level, CI/CD variables can be stored outside the individual projects, and securely passed into pipelines across multiple projects.
Are there any way I can do that in Gitlab CI?
Sample usage of context in Circli CI for your reference
version: 2.1
workflows:
staging-workflow:
jobs:
- staging-build:
context:
- staging
prod-workflow:
jobs:
- prod-build:
context:
- prod
I think you could achieve something similar by utilising gitlabs schedules.
Simply create two schedules that contain the variables you want to pass.
Update your ci script to reference these variables.
Then each schedule can be owned by the respective parties.
You can also limit variables by group, based on which environment. So if you have a dev env - variables can be limited for that and the same for a prod env. Hope this helps.
Finally I got this problem fixed with Gitlab CI enviroments
set environments Staging and Produciton
when it asks for url, ignore the issue, put any url you like, I just put http://example.com .
still not sure the proper url I need put in.
update your variables in cicd, default is to all, change it to staging or Production.
Setting -> CICD -> Variables -> Expand
in the screenshot, I set variable AWS_ACCESS_KEY_ID two times, but assigned to different environments.
(Notes: AWS_ACCESS_KEY_ID doesn't need be masked, but AWS_SECRET_ACCESS_KEY should be)
update your pipeline to use the enviroment.
the gitlab ci environment document above confuse me again. you don't have to provide the url, just add the environment name is enough.
staging_deploy:
stage: deploy
environment:
name: staging
when: manual
script:
- echo "staging deployment"
Azure DevOps XDT Transform tasks allow you to build release profiles that transform the base config file with settings that are specific to each environment, such as a connection string that points to different db servers for different environments. The app.dev.config file has transformations for the dev environment, app.qa.config for qa, etc, which are applied during the deployment to the base app.config file.
I need to take this one step further and deploy custom config files for each individual server in a load balanced environment. For example, the DEV environment has two servers dev1.mysite.com and dev2.mysite.com that are load balanced by dev.mysite.com. Each of the two servers needs specific settings in the config file deployed to that server.
I don't (yet) see a way in Azure DevOps to do this. Part of the solution might be to set up variables with the setting that needs to be applied to each environment/server but I haven't figured out how to apply the correct variable to each config.
You can use task Magic Chunks to apply the variable to each config.
You can search for Magic Chunks task in your pipeline and install it to your organization. Then add Config transform task before the deployment task to update the config file with specific setting. For below example settings of magic chunk task:
As above screenshot shows, You can reference your pipeline variables in the tasks.
There are other extension tasks like RegEx Find & Replace you can use to replace the variables in the config files.
I got a Visual Studio solutions with multiple projects (function apps and a web API) and a datalayer that is shared between all the projects. I've set up the solution so all projects share the same config (appsettings.json) based on this article: https://andrewlock.net/sharing-appsettings-json-configuration-files-between-projects-in-asp-net-core/
All projects are based on .net core.
I've set up a build and a release pipeline for the dev environment. But I need a Test and production environment. How do I transform the shared config before releasing it to the test and production environment?
You don't. That's not how configuration works in ASP.NET Core. Configuration is overridden, not transformed. There's an order of ops to how the different configuration sources are applied, which is basically the order in which they're registered. The default is JSON < Environment-specific JSON < User Secrets < Environment Variables < Command-line Arguments.
If you need configuration to vary by environment, you're going to rely on the environment-specific JSON files (for general config) or environment variables and/or something like Azure Key Vault (for secrets). Since all of these come later in the configuration registration, any value you set there will override the values in your appsettings.json.
For things like environment-specific JSON, which is loaded is dependent on the value of ASPNETCORE_ENVIRONMENT, which can be set as an environment variable or passed as a command-line argument --environment. In either case, the value set corresponds to the {environment} portion of appsettings.{environment}.json. In other words, if you set the environment as Production, then appsettings.Production.json will be loaded into the config, if it is present. Environment variables are tied to the environment itself so are not dependent on any particular environment value.
Before I was shown Octopus Deploy I thought that environment dependent appSettings should be a part of Build Configuration in project properties.
Now in times of software as a service it is a deployment process that buckles everything up.
I want my environment configuration in release process to just open web.config and substitute appsettings and connection strings based on variable names i defined for the release definition.
How can I do it? The closest I could get was Magic chunks. The problem with it is that I have to give it a json with the mapping and I have to define it for each environment separately, so it makes no use of environment variables, really, or at least you have to define it in "enviroment variables" section and then, again, in each process of environment.
You can use the "Tokenizer" task in "Release Management Utility tasks" extension or "Replace Tokens" task.
These tasks can replace the strings in a file with the custom variables in definition.
I'm trying to set SQLCmd variables based on configuration (Debug / Release, etc) but the Configuration dropdown is greyed out (see image below). For Dev environment, I want the SQLCmd variable to be Stage, for the Release environment, Prod.
I can't figure out an easy way to do this without going into the properties. We have 9 projects and about 6 variables each. Each time we do a schema comparison we have to manually change the variables and it's very tedious.
Our publish scripts are fine for the different environments, it's just setting up for schema compare that makes it time-consuming.