We have a few drop down list validations that a couple of users modify occasionally. Currently we have given them access to make the changes in our Production environment. This caused a problem during a recent migration, where the validation was incorrectly migrated from Development to Production. We are exploring several options to avoid this in the future.
1) Remove all access to update validations in production. All changes will be made in our Development environment and migrated to QA and then to Production. Users that have been used to making these changes when they need them will obviously complain about this.
2) Modify our migration workflow to allow the validation to be moved from Production to Development. This option makes everyone nervous since we normally never migrate downward.
Our Development Management is pushing for option 1, but asked me to find out what others normally do in cases like this.
-- Remember to give Kudos to answers! (click the KUDOS star)
From a Best Practice point of view, option 1 is definitely the best. You don't want to be making changes directly in Production. However, I have also implemented option 2 in conjunction with option 1. Part of the change management process we implemented is to take the version in Production and move it back into Development to ensure that you are starting from a "good" version of the configuration item when it's time to start development. I also added a new field to the Object Types to indicate whether or not this is an existing object since you can't back migrate something that doesn't exist in Production. There is a step where a Release Manager reviews the package lines to determine if the back migration should be performed or not. One instance where it would not need to be done is where there are multiple CRs (and subsequent packages) that would modify the same item. The second CR would not need to migrate from Production as it would have been from the first CR and if the first CR had started its work, then those changes would be lost.
I have a better and simpler solution which might suit you better. I have the same situation in several customer environments.
The solution I chose is as follows:
Your validation gets migrated along with the request type (presumably because it is linked directly to the field). What I do is create another custom validation which is based on simple custom SQL selecting the same values as the original validation. Then, I link the second validation to the request type field(s). In this approach, only the SQL-based validation gets migrated and not the one which contains values. For the original validation, you can check the "Used By" button in order to identify the fields that are "dragging" the validation along in the migration process.
The above approach will keep your environments in sync at configuration level and you do not need to worry on validation data getting overwritten.
Do let me know how it goes.
--remember to kudos people who helped solve your problem