[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Promoting deploymentconfigs etc. from dev->testing->production



May I ask in relation to this, how do you define an "environment" at the moment? My first instinct was to create a project for one app and configure different service/deployments referencing different image tags (e.g. dev, test, etc). Given that all services within a project are automatically injected env vars to find other services, this doesn't really work. So it seems I need a project per app per environment. And then a single PROD project? That's an awful amount of projects. Is that a common current practice ? 

Thanks

On 6 September 2016 at 01:21, Ben Parees <bparees redhat com> wrote:


On Mon, Sep 5, 2016 at 8:59 AM, Pieter Nagel <pieter lautus net> wrote:
All documentation I've seen so far shows how to build a Continuous Delivery pipeline by tagging a specific image for testing/deployment.

But apps consist of more than single images, they also consist of surrounding deployment configs, services etc. that combine all together into a working system.

How does one manage the promotion of the entire set of these through the entire CD pipeline?

In effect, I want to take a specific deploymentconfig from which a specific "known good" deployment in development was created, and clone that into testing -> production, along with related services and routes, except that image references should be rewritten to reuse the exact same "known good" images.

​Yes this is a space we are actively investigating.  As you note, there are two parts to promotion, one being the promoted "content" (images, normally) and the other being the promoted "configuration".  Today for promoting configuration the basic flow would be to do an "oc export" from one environment and then "oc apply" those resources to your next environment (possibly with some manual transformation of the resources in between).  But Gabe and Justin from my team (on CC) are actively working on how we make that story better.  Keep an eye on these trello cards:

https://trello.com/c/HlQpE52w/848-8-provide-example-of-promoting-application-between-datacenters-projects-evg
https://trello.com/c/Mvuy5Afi/993-8-define-an-environment-resource-r-d

The first one is intended to develop some documentation that users can use today to manually go through promotion flows via oc export/apply/etc, but with more prescriptive direction.  The second represents our longer term vision to make promotion between environments a first class feature of OpenShift, with specific tools for accomplishing it.

​I'm sure Gabe and Justin would be very interested to hear more about your specific use case in order to ensure it is covered as they are thinking about this.


 

Is there a better procedure than "check if the definition of the deploymentconfig changed during the last cycle, and if so, `oc apply` the relevant changes to the testing/production projects before tagging the image"?

--
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540

_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users




--
Ben Parees | OpenShift


_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]