IBM APIConnect | API Version and Deployment Strategy
There are multiple Approaches to maintain API/Product version in APIC for Deployment. this article covers two most popular approaches
Approach A: Product and API YAML version maintained in Git(or other SCM)
In this approach, the YAML is maintained in Git(or other SCM). the APIC Yaml “info.version” is changed only for “in-compatible” changes.
For backward compatible changes, the “info.version” is not changed. for any reason, a change has to be rolled back, get the previous code from the SCM and re-deploy.
Approach B: Product and API YAML version maintained using APIC versioning
In this approach semantic versioning is expressed as MAJOR.MINOR.PATCH. (e.g. 1.0.0, 1.0.1, 1.1.0, 2.0.0) within APIC YAML info.version field.
These fields are incremented as follows:
MAJOR version when you make incompatible changes, which impacts existing consuming applications.
E.g.
For Products, changing existing Plan Rate Limit
For APIs, introducing a Mandatory field to request/response. Ensure the BasePath is updated with the major API version. i.e. /v1 or /v2 or /v3 etc.
MINOR version when you add functionality in a backwards-compatible manner. E.g.
For Products, introducing a new API, adding a new Plan
For APIs, introducing optional field to the Payload, changing backend URL or interface change
PATCH version when you make a backward-compatible bug fix.
E.g.
For Products, changing product description
For APIs, Any Bug fix in the existing API Code
Once the Products/APIs and version are updated, its important to follow below strategy for Deployment
Note: enable “production mode” in Catalog → Settings for this approach
References:
Disclaimer: the above strategy is some of the best practice recommendation. carefully analyse the approach and implement as per Business needs.
