Should services be managed in a Version Control System?
We're working on a project with both the Gateway and the Developer Portal, and we want to use git as version control system.
Question: Should we be versioning only the policies and its dependencies? Or also the services being published?
Additional note - We expect to have 3 environments: dev, test and prod.
Any insights are greatly appreciated.
Thanks for your quick reply. I've already followed the instructions of the link you provided, which have been really useful for some testing we've done so far.
I guess what confuses me a little bit is when the Developer Portal comes into the picture, and how all the pieces (Policy Manager + Developer Portal + Multiple environments) should align in a release strategy point of view. For example, If I migrateIn a service into a given environment, that service will not be portal managed (even if the assertion "Set as Portal Managed Service" is present). So, for these services the Portal will be more of a read-only tool, am I correct?
1) What version of the Portal are you using?
2) How many Portals are you running?
3) How does the Portal align to the various environments?
1) We're using version 3.5.
2) We just setup a Portal per environment (dev, test, and soon, prod).
3) I believe this is part of what we're trying to figure out .
To move Gateway metadata across different environments, GMU is the right approach. To move Portal metadata such as API Keys (Applications), it would need to be done manually since Portal 3.5 has no APIs. With Portal 4.x, there are system APIs that would allow for Portal metadata to be moved across programatically.
Thanks for your reply. Do these system APIs in Portal 4.x include calls to enable a migrated API via GMU? And add API Owner groups? I've also noticed that APIs published via GMU are disabled and with no API Owner group.
The 4.x Portal API calls allow for the updates and would accommodate for the use case you described. The API Owner Groups does not exist yet in Portal 4.x, but you may be able to achieve similar functionality by using an organization to group users and APIs, and then extend the access permissions of those organization admin user to manage their own APIs.