Hi, I am looking to implement a solution and hoping to get some advice.
We have Users which have permissions to amend project variables in both Development and Production Environments.
Previously, the wrong variable has been changed and as a result has been deployed to Production.
We could give each User 2 separate accounts (1 for Dev and 1 for Prod).
But, this would be more of a burden on the User and I wanted to explore other options before doing this.
Thanks.
Hi Jay,
Thanks for reaching out to us today regarding your issue, and I’m sorry that the wrong variable went to production.
Do you want your team members to be able to change production values at all? If not, we might be able to solve that with some variable permission scoping for example the guidance here shows how to control the environments a team can access, and users can be in as many teams as makes sense for your business.
We’re interested to know what actions led up to the mistaken change, there might be UX improvements we could make to prevent from occurring in future. Was it a case of confusion about the scoping of the variable itself?
What kind of application are you trying to deploy? Another more convoluted option for .NET applications that comes to mind is using separate variable names for production and development settings and using configuration transforms during the deployment process to leverage them, however this isn’t necessarily useful for other types of deployments.
Kind regards,
Hi Jim
We do have a handful of Users who are able to change both production and development variables.
I believe this is not best practice?
We do use .NET applications and most of the variable names within projects are the same for all environments. This is how the accidental change occurred.
I’m not sure how the separate variable names for prod and dev would work if both replace the same hard coded variable in the config file?
Would i be right in thinking the best/only way forward would be for the handful of Users to have 2 separate accounts?
Hi Jay,
I believe this is not best practice?
Generally speaking, it’s good to separate duties in development and production, but even then mistakes can happen. It isn’t always practical to say that “person A can only access development” though and revoke their access to production environments.
I’m not sure how the separate variable names for prod and dev would work if both replace the same hard coded variable in the config file?
One idea comes to mind is to provide some environment hinting through the use of variable naming and interpolation. This doesn’t prevent the scenario entirely, but it might users with permission in both environments more of a hint.
As an example of what I mean, you can have a setup like this:
DatabaseConnectionString is the variable that is used in configuration, the other two are just used to resolve that value. These can be named in such a way to be more obviously used in a particular environment. This might be enough to prevent accidents.
As you’ve stated earlier, the only way to give somebody who needs Dev & Prod access a safety mechanism is to provide them two different users with different permissions.
I hope that helps, and please let me know if I can assist further with any of the above details.
Kind regards,
Thanks Jim, sorry it took so long to reply, been busy with other tasks.
I think we’ll just have to go with 2 separate accounts to access Dev and Prod.
