We have team of 5-6 developers working remotely on two locations. All are working on APIs development those would be served by Tyk on production.
We want all authentication (Key Based, OAuth) on the Tyk side and would receive only authenticated requests to our controllers. What’s the best workflow to streamline development of APIs using Tyk in production.
One path that I have in mind, to setup Tyk on a server in local network where each developer can setup their on endpoints to test/develop their APIs. But since we are working on two locations this may not be feasible.
Please suggest best workflow as per you guys thought.
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.
An easy way to attach Tyk to the services they are building locally
Set up / tear down locally
A way to attach in CI for integration testing (maybe)
A way to update their environment to match current stable state (e.g. should have the same - but specialised - configurations as Develop env, QA and Staging)
B) Requirements for an infrastructure management and deployment team:
Secure access to staging and development environments dashboard
Deploy new routes / changes etc across instances for roll-out
I think that Tyk tagging feature is really useful here to share out work without multiple copies of API Definitions floating around
A possible dev flow
Developer pulls company-specific Tyk docker image for setup (GH repo like our quickstart using docker compose)
Docker container does not have local DB-backing, instead points at a shared Dev DB
Developer modifies the configuration file for their container with a set of tags: “dev-box”, “dev-id” (or username)
Developer logs into dashboard (this could be a shared dashboard, or a local one - recommend shared so as not to make things difficult), this could even be done with a bootstrap script
The local gateway will load all centralised (stable developer-ready definitions for running services, tagged as “dev-box”, AND their private ones (tagged with their developer ID)
When developer sets up new test APIs or wants to work with local ones, they simply add them to the central dashboard but tags them with his own developer ID, this causes only his box to load those definitions, so there’s no externalities with other team members
Dev can extend the tags to include other dev boxes by adding their dev-ids as tags to his API def.
When the service is ready, the service itself can get pushed to CI, the corresponding dev API def can be exported and handed over to the management team for import, they tweak and make it ready for staging / live etc. And export it into a GH repo for version control
A team could then use the GH repo to bootstrap a whole dev / live / staging environment with approved API definitions using the Tyk API, or just pushing those definitions onto Tyk boxes that are using a file-based approach.