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
>> 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
>
>
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to