In CD environment, I would like to see a single source of truth (git), and go through usual engineering workflow for API contracts too, with review/collaboration on API specifications (aka. typically Pull/Merge Request on specification changes) and manage API specifications as code…
That would mean asking developers to edit source files (yawl, json) instead of the nice designer UI provided, but that approach can remove manual edits, allow listing, improve consistency and in the end quality. Use the UI for junior, to setup, but the industrialise the next steps when the team matures.
Do you have a way to deploy Tyk api routes, specifications, documentations, secrets (git-crypt) through a Git-based CD flow?
I have seen an article on tyk-git as a way to export the config changes done in the designer UI, as an output of development, and then move it across the deployment lifecycle. Is that the recommended approach?
Take a look at the following example workflow with Jenkins.
You can create APIs in local dev env via UI.
Export and commit to github.
Other developers can pull your changes and sync with their local dev env.
You can then create your PR.
Jenkins multi-branch pipelines can check to see if is a PR or a release.
When the release is ready (based on git tag) Jenkins can auto-deploy to production.
In example above, I get jenkins to do some very basic unit-testing, e.g. ensuring that Auth is enabled for all APIs.
You can fully manage the config to/from git.
There is good workflow with basic checks.
We can extend with deeper checks when merging by learning from our mistakes.
That’s great. The Jenkins CI/CD example is a very basic example which I knocked up to learn Jenkins, and also to simulate how our some of our enterprise clients use Tyk with CI/CD in their production infrastructure.
If you have any feedback to improve it, please do let me know - or feel free to submit an issue/pull request in the github repo.
Again, your example is good. All the blocks are there
My main feedback which is usually what advanced organisations will invest on, is around full CD
Remove UI / mouse from the CD chain (cf. UI = mistakes, zero consistency, etc…)
Allow engineering practices (git): feature branch, code review, merge of 1 change at a time to one permanent branch (and move away from one branch per environment)
Real CD: once reviewed/approved, each feature goes with zero manual step from change to live.
