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 <bpar...@redhat.com> wrote: > > > On Mon, Sep 5, 2016 at 8:59 AM, Pieter Nagel <pie...@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 >> firstname.lastname@example.org >> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >> >> > > > -- > Ben Parees | OpenShift > > > _______________________________________________ > users mailing list > email@example.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > >
_______________________________________________ users mailing list firstname.lastname@example.org http://lists.openshift.redhat.com/openshiftmm/listinfo/users