Component Parameter Updates: Service Accounts for External Tools
search cancel

Component Parameter Updates: Service Accounts for External Tools

book

Article ID: 227650

calendar_today

Updated On:

Products

CA Release Automation - Release Operations Center (Nolio)

Issue/Introduction

How can we update Environment parameter values across all applications? 

 

Environment

Release : 6.7

Component : CA RELEASE AUTOMATION ADMINISTRATION

 

Resolution

Summary: 

It is understood that there are Components/SharedComponents with Environment Parameters defined to specify things like Artifactory, TeamCity, etc.. connection details (url/servers, users, passwords, etc..). 

Three options to consider:

  1. Convert the environment parameter(s) to internal parameters. Environment parameters are ideal when values may differ between deployment applications and/or environments. 
    1. If parameters exist in non-shared component(s) then each non shared component, in each application, would need to be updated. Then the processes that use that component would need to be re-published. 
    2. If parameters exist in a shared component then each shared component would need to be updated, each application that used the shared component will need to be updated to point to using the new revision of the shared component and then all of the processes using that shared component would need to be re-published
    3. If there are parameters that are global then setting it to an internal parameter will minimize the number of updates that need to take place. Potentially reducing it down to:
  2. Write a script (maybe powershell, bash, or Nolio Process - see Additional Information) using the APIs reviewed during our WebEx. An idea of what the script may look like included:
    1. Providing a array/list of all paths (across all applications, environments, shared components).
    2. Get all applications
      could use: http://server:port/datamanagement/a/api/v4/applications?only_active=true 
    3. Loop over all applications to get list of all environments
      could use: http:/server:port/datamanagement/a/api/v4/applications/324/environments?only_active=true
      - requires: appId
    4. Loop over all environments to check if there is a specific environment parameter name
      could use: http:/server:port/datamanagement/a/api/v4/get-environment-parameter
      - requires: appName (or appId), environmentName (or envId) and parameterPath (which is why you need to take inventory of paths used by components)
      example get request data body:
      {
       "application": "TestGJS"
        "environment": "Test"
        "parameterPath": "OracleDB/envpass”
      }
    5. If the environment parameter does not exist, continue.
    6. If the environment parameter does exist, update environment parameter.
      could use: http://server:port/datamanagement/a/api/v4/update-environment-parameter
      - requires: appName (or appId), environmentName (or envId), parameterPath (which is why you need to take inventory of paths used by components) and New Value
      example post request data body:
      {
        "application": "TestGJS",
        "environment": "Test",
        "parameterPath": "OracleDb/envpass",
        "simpleValue": "AdminLvl!"
      } 
    7. Then, when an environment parameter needs to be changed:
      • run the script (providing the new value as an argument/prompt). No shared components should need to be updated, no processes should need to be republished.
  3. Another option, which might help reach minimal touch/updates when things like password changes happen, might be to:
    • Not hard set values for connecting to external systems.
    • Instead, write workflow in nolio (components/shared components) to retrieve values from some type of password/secret management tool. Maybe a tool like HashiCorp Vault and/or Cyberark.
    • Though a potential exists for needing to periodically touch/update access information for such a external password/secret management tool. 

 

 

 

Additional Information

The following KB Article offers an example process that loops over all environments within all applications. Something like this might serve as a base for the loop needed/described in option 2 outlined above. 

KB Article: Looping through Application Environments