What mechanism would you use to control the bleed from the old to
the new application? This component would most likely be out of the
scope of OpenShift. You would be able to deploy both versions of the
application in OpenShift side by side.
What type of cartridge is the application? Would you be using
OpenShift's Jenkins cartridge to manage the builds and deployments
or an external Jenkins?
On 1/14/13 12:57 PM, Brian DeCamp
I originally posted this
on the community forum, but Nam suggested I post it on the dev
I'd like to
use OpenShift Origins or Enterprise to manage a Continuous
Deployment pipeline for a large (30MM+ user) application. Our
SOA will also A/B test every release as it goes out,
automatically failing a release that does not meet certain
thresholds for KPIs. To do this, I need to control the
deployment of the new build into production. When a build
successfully passes all our tests in Jenkins, I'd like to
install the new build into production without removing the old
build. Then I'll slowly bleed traffic over to the new version
while monitoring our KPIs. If all goes well, all traffic will
eventually use the new version and I can remove the old
version. If not, I'll redirect all the traffic back to the old
version and remove the new build. Traffic routing will be
through HA Proxy for web applications, and through a custom
message broker for backend services.
possible to do this all with the deployment hooks? If not, is
there someplace in the Origins code I can look to scope out
the amount of work involved to meet these requirements?
dev mailing list
dev lists openshift redhat com
Principal Software Engineer, Red Hat
wdecoste redhat com