...
- Variables
- Distribute variables into classes
- class: Main: Okapi Host, Username, Tenant
- class: Main (workflows specific): edge-host, API Keys
- class: Load: User, duration, ramp up <-- workflow specific
- class: Flow-based: profile, file <-- workflow specific
- Passing in variables from Jenkins job.
- Json JSON configuration that has configurations for each workflow
- Pros: Does not need to create a long list of parameters in the Jenkins job.
- Cons: Long file, hard to work with.
- Store the workflow configuration file on Github (pull it down when building the job)
- Pros: Changes to the config are documented as Github as commit comment each time the file is checked in.
- Cons: The configuration still needs to be in some form (JSON, XML, plaint text/csv, etc..)
- Store the workflow config file in Artifact package
- Pros:
- Cons:
- If a slight change to one of the parameters is made, a new artifact package will have to be recreated.
- Need to keep record of the versions of the packages that have whichever changes.
- Expose the parameters directly in Jenkins as text boxes and other controls (drop down lists, check boxes, etc..)
- Pros:
- Cons:
- A very long Jenkins job that may have well over 200 parameters.
- Json JSON configuration that has configurations for each workflow
- Distribute variables into classes
- Probability of calls (TBD - with small POCs)
- Flow based?
- tenant/cluster based - to control the distribution of calls to the workflows.
- Implementation:
- Smaller thread groups easier to manage, debug
How:
Pros:
Cons: - One thread group
How:
Pros:
Cons:
- Smaller thread groups easier to manage, debug
- How to retrieve secured variables like username, password?
- Automation: Any modifications to the current Jenkins job needed?
- Script size: How big is too big? Can it reasonably accommodate 30-40 workflows?