I am wondering what approaches other developers manage their context files.

I found two different approaches to use context files and I think there are some limitations with both of them, maybe someone has encountered the same problems as I have and has a good idea how to handle these problems.

1. Have different context files for different environments (e.g. LOCAL, DEV, CI, UAT, PROD) which allows you to develop  and test jobs appropriately on a local machine and at deployment time allows you to define the appropriate context file depening on the environment you are. The limitation I see here is that the job will always provide you with all options of context files although I don't want the developer to be able to run the UAT context file on CI.

2. Have a Default context file in every environment and read that via tContextLoad in your job. This becomes a problem if you are trying to run the job on a local machine where the destination of the context file is different from the destination on the environments (e.g. development of job on windows, execution environmens on linux).

I'm looking forward to hear about some best practices and hints on how to overcome these limitations.

Last edited by jrox (2012-04-27 21:18:30)