One of the biggest problems we have with our current infrastructure/process
(and which we are trying to address with Openshift) is multiple teams
fighting for shared environments (test, uat, stage, prod). This led to a
terrible "deployment train" anti-pattern with 4 big releases a year to
promote apps through the environments. If you missed the train in dev you
have to wait for the next one.

Anyway, maybe an Openshift project per app is too extreme but we want more
than one dev, test and stage to give different teams their own path to
prod.

On 13 October 2016 at 14:20, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Wed, Oct 12, 2016 at 10:04 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> 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 ?
>>
>
> one project per "environment" (dev, test, stage, prod) is certainly one of
> our recommendations (a cluster per environment is another valid option).
>
> not sure why you need a project per app, however.  (you may have your
> reasons, but it's reasonable to run multiple apps in a single project as
> well)
>
>
> ​
>
>
>
>>
>> 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-promo
>>> ting-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
>>>
>>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to