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