artifact consistency across environments

[#1]

In order to make the best use of our CI process, we would like to build API Proxy artifacts (zip files) that are _consistent_ across the environments (dev, test, prod). i.e. Build once, deploy to multiple environments. So rather than have build-time replacement of xml elements in the API proxy files, we would just follow a best-practice of ensuring that *all* environment-specific configuration is stored in either Target Server, KVM, or Vault. Does this sound like a reasonable approach?

This is what we have done for all of our java artifacts (jars, wars, ears, etc.) in the past and it has worked well.

[DChiesa]

YES - totally reasonable approach. And a good practice to follow.

If you do this, you also need separate artifacts or data files for the TargetServers, KVMs, and Vault, and all those things need to be provisioned or checked at the time you import + deploy the proxies into dev, test, prod.

At the moment there is no way to "bulk export" those settings from an environment, so that you could check it into a source code repo. And there is no corresponding "bulk import". But it should be straightforward to provision all of those using the documented Administrative APIs for Apigee Edge.

[dcouldwell]

A couple of things to consider

1. What is your source of truth?
   Based on what I've seen organisations choose to either have source control or artefact control as their source of truth.
   i.e. where do a go to get the definitive copy of proxy X in environment Y and do I control anything that's environment specific at runtime or build / deploy time.
   The approach above sounds like you're using looking at artefact control which is a valid approach.
   The main point being choose one as the source of truth, don't mix and match. I would say it's still valid to have some build time and some runtime control but have one source of truth for the base bundle.
   I would say based on my experience the majority of organisations use source control but there's nothing wrong with using artefact control you just need to ensure 2) below holds true
2. Can everything that you care about be controlled at runtime?
   If you're going down the artefact control route i.e. the same artefact is used in all environments this assumes that anything that's environment specific can be controlled at runtime via KVM, Target Server or Vault and no build / deploy time replacements will happen.
   Some policies don't support runtime variables e.g. the access control policy cannot be controlled using variables.
   In these cases you'll need to consider other options if you want your bundles to be identical e.g. writing the functionality yourself in JS as opposed to using the out of the box policy.
   The balance then will be to decide if the need / benefits of having exactly the same bundle in all environments outweighs the additional effort in some cases to support that pattern.

[akoo]

Hello all, I wanted to add an important note: encrypted KVMs are here. Details are in our documentation: http://docs.apigee.com/api-services/reference/key-value-map-operations-policy . You now have an option for encrypted data without having to use Node.js.