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 (
can have a look to this function :
On Thu, Oct 13, 2016 at 4:04 AM, 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 ?
> 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:
>> 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
>>> Pieter Nagel
>>> Lautus Solutions (Pty) Ltd
>>> Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
>>> users mailing list
>> Ben Parees | OpenShift
>> users mailing list
> users mailing list
users mailing list