I’ve been trying to come up with a similar strategy for our team once we start using Tyk. I think the solution depends upon what your requirements are.
- Is your team the one deploying & configuring Tyk, or are they using it more as an appliance? Both?
- How much customization do you plan to do?
In my case, I need a strategy where a couple developers, lets call them Team #1, are directly managing/deploying Tyk, but other developers, Team #2, only add new API’s, build microservices behind Tyk, perform QA, and generally use Tyk as an appliance.
For Team #1, we want everyone to be able to setup/teardown Tyk locally and then deploy updates periodically. We are using Docker deployments to enable this ecosystem which makes snowflake problems less an issue. This team would also maintain a Dev environment for Team #2.
For Team #2, will only use the Tyk API’s to build API Definitions, policies, etc. So, they will not need to setup locally at all. They will just use http://dev.somedomain.com:3000 or somesuch to hit Tyk’s API during deployment of new routes/configs (we arent exposing the dashboard yet).
By using the Tyk API Definitions and API’s the teams can commit their deployment scripts to a git repo independent of the Tyk repo.
Anyhow, thats as far as my thoughts have gone on this matter.
Other real-world examples would be great as we havent started doing this yet and its only theory at the moment.