StuartSmith75811464

GMU templating best practices

Discussion created by StuartSmith75811464 on May 17, 2017
Latest reply on Nov 2, 2017 by acalbazana

Please assume for a postulate that I am familiar with all current GMU docs online.

 

I am wondering how people are managing an automated devops workflow properly with GMU ?

 

The issues I see are many:

 

- the template is tied to the specific export - it is not generic or reusable. Some quite advanced merging would be required to make it so.

 

- though CWPs appear at the top and will be where some parameters which differ per environment go, many changes are not CWPs. These include backend trusted certs, IDP identities, LDAP configurations, RBAC roles and users, etc,etc. 

 

Take for example, an HTTPS backend server you are using in an API:

 

In your dev environment this will have a cert in your certificate store for SSL outgoing. In order to promote this API to your test environment, you export the API with GMU. If you are lucky, GMU picks up that it needs the trusted cert and exports that too.

 

You template that. In order to create a TEST template to configure the API to work properly once GMU migrated into TEST, you will need to modify not only your CWP that points to the backend (since it's of course now a different machine in your test environment), but also add the relevant public cert. This is non trivial - you will need to find the cert in the template, and then someone get hold of the cert from your test environment and paste it in (perhaps you had to grab this via the test PM). And repeat for every similar backend. For LDAP settings, users in IDP, etc it's going to be similarly quite a pain and very very manual.

 

I imagine what you could do, is pull out JUST those items from the template as the TRUE template for your test environment - because this is the stuff you are going to need for the next release...BUT:

 

On your next release, you'll have to do this all over again - since the template will have all these scattered over the dev output again - so you'll have to say, have some sort of script that goes through replacing all those name/value pairs with the ones in your TRUE dev template. It's quite crufty. 

 

In order to have a fully automated DEVOPS process I should be able to:

 

- have a process I can run which completely sets up a new environment based on a common set of configuration (i.e. build) with whatever environment specific data is required.

- have no need for any manual stages. no need to create any artefacts manually via policy manager, etc

The above is a pretty basic definition of what automated deployment config management should be.

 

It seems to me we are still a long way from that with the GW, without a significant amount of effort - and I'm wondering how many customer have actually carried out that work so far?

 

Frankly, the only way I can really see this as working in a true production fashion is with manual configuration happening on PM on the target environment, and that defeats much of the benefit of devops automation.

 

I'd like to see a non trivial worked example - end to end - which includes the resources above - which allows REPEATED delivery of builds from your dev environment to one or more higher environments completely handoff/automatically via scripts.

Outcomes