Basically, there are three ways how you can handle this information:
- store the information within the workflow activity
- create a workflow variable
- create a workflow constant
Most people start with alternative 1. The environment specific information is directly configured on the workflow activities. This has one advantage: You are pretty fast when you configure the activities the first time. But in the long run the disadvantages outweigh. After deploying the workflow from environment to the next stage, you have to update all affected activities. Beside the fact that this is time-killing, it is also error-prone. Furthermore, such a workflow requires some effort if you put it under source control. For every functional change you implement, you have to update all workflow variants (e.g. for development, test, production).
|Alternative 1: Configuration values are set in the workflow activity.|
With alternative 2 you will set the workflow variables carrying the environment specific information to the beginning of the workflow. So you do not have to scan the complete workflow for activities that require an update. Consequently, the risk of a faulty configuration is also mitigated. But you still have the issue, that you have a workflow variant for each environment which has to be maintained in the source code management system. And this method cannot be applied to credentials for service accounts.
|Alternative 2: Configuration value is set in the beginning of the workflow.|
The issue that you have to maintain a variant for every environment is resolved with alternative 3. In this solution you create a workflow constant for every environment information your workflow requires. Therefore the workflow does not have to be altered when you deploy it into another environment.
|Alternative 3: Configuration values are set with workflow constants.|
How workflow constants can be created using a script will be featured in my next post.