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 a
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://gith
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
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
injec
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,
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.
