Should services be managed in a Version Control System?

[Jaime Solano]

Hi guys,

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!

[Stephen Hughes]

Jaime,

 

As the service themselves have certain configuration set it is recommended to do both policy and services. Services have policies aligned directly and can reference other dependencies including encapsulation assertions aligned to policy or policy fragments so the more inclusive you are about versioning the easier it will be to move entities between environments. This link outlines some ideas on how to use GMU to do versioning. Version Control Example - CA API Gateway - 9.2 - CA Technologies Documentation 

 

Sincerely,

 

Stephen Hughes

Director, CA Support

[Jaime Solano]

Hi Stephen,

 

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?

 

Best,

-Jaime

[Stephen Hughes]

Jaime,

 

A few questions in regards to your last post to help shape a proper response on how this works:

 

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?

 

Sincerely,

 

Stephen Hughes

Director, CA Support

[Jaime Solano]

Stephen,

 

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 .

 

What is your recommendation?

 

Thanks,

-Jaime

[kovbo01]

Hi Jaime,

 

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. 

 

Boris 

[Jaime Solano]

Hi kovbo01,

 

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.

 

Thanks again,

-Jaime

[kovbo01]

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.