You are not logged in.
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)
Alright found a way: I was not aware that tContextLoad does not fail if it points to a non existing path or folder.
Use tContextLoad to point to the context file sitting on the environment and since that does not exist on the local machine it uses the context that is used to run it. The context selected to run from TAC will be overwritten by the file sitting on the environment.