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

[Lionel Orellana]

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  wrote:

>
>
> On Wed, Oct 12, 2016 at 10:04 PM, Lionel Orellana 
> 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  wrote:
>>
>>>
>>>
>>> On Mon, Sep 5, 2016 at 8:59 AM, Pieter Nagel  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

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

[Charles Moulliard]

Hi,

I think that it could be interesting that we involve within this discussion
what Middleware team has developed as we propose within the pipelines
scripts such possibility to move a "project" between different namespaces
(dev -> test -> prod) including also approving or rejecting (
https://github.com/fabric8io/jenkins-pipeline-library#drop-project). You
can have a look to this function :
https://github.com/fabric8io/jenkins-pipeline-library#deploy-project

Best regards,

Charles

On Thu, Oct 13, 2016 at 4:04 AM, Lionel Orellana  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 ?
>
> Thanks
>
> On 6 September 2016 at 01:21, Ben Parees  wrote:
>
>>
>>
>> On Mon, Sep 5, 2016 at 8:59 AM, Pieter Nagel  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
>>
>>
>
> ___
> 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

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

[Ben Parees]

On Mon, Sep 5, 2016 at 8:59 AM, Pieter Nagel  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