PaaS came from the desire of developers to be provided with a pre-defined service layer that may consist of multiple tiers (Application Server, Database, Messaging Systems, etc.) and sits upon a platform that is provisioned using an automated IaaS platform like OpenStack.
OpenShift Online provides you a free service where you can try a PaaS platform. But how does this 1:1 mapping between a developer and the development environment help inside an enterprise enterprise environment, that consists of multiple developers working in teams. With these teams working on different components of a distributed application. This article tries to give you an idea about how to utilize an On-Premise PaaS for your Enterprise.
Take a look at the following picture shows a typical Continuous Delivery Lifecycle that consists of 3 different development teams on the left. Each Team (A,B,C) develop on their own feature branch. That branch is tied to an OpenShift gear. When the developer issues a git push, the code is pushed to the remote repository.
Each push triggers a jenkins build in a centralized jenkins instance. You can integrate with an existing jenkins instance as well.
The development team can then review their development efforts and release the code changes into gerrit for code review.
When the changes are accepted another jenkins build is issued. That build creates an integration gear against which the integration tests are run. When the integration tests have run without any issues, the code changes are merged into the Enterprise Master Code Repository. That merge triggers a release build of the software (this can result in an automated tag, depending on your release naming/versioning convention). The built artifact is released into nexus.
From now on each release is no longer rebuilt from source, but the released artifact is used for deployments. This ensures complete traceability in case of an error. With the released artifact at hand, it is possible to do various things. You could automatically run load and capacity tests against the released artifact. You can issue a mail to a UAT Team, that a specific release is ready to be tested. All they have to do is select the software version and deploy it to their On-Premise PaaS. OpenShift provides a binary deployment feature for that use-case.
The nice side effect is that such a deployment will be considerably faster than Virtual Machine based deployments. A pre-defined test environment with the correct software release will be available in minutes instead of days.
After the UAT Team is done and the software release is ready to be released into production you can trigger a custom Infrastructure Deployment Process or use OpenShift for production (OpenShift provides horizontal scaling capabilities out of the box).
However your Deployment process looks today, you can use new technologies like PaaS to integrate it with it. What a PaaS enables you to automate is integration, load and capacity testing, because test environments no longer need to be shared and hence tests need to be queued, nor does the the deployment of these environments take hours and clogs your IT Infrastructure. Highly dynamic environments are created and torn down as needed. Results are tracked and reported. If a code change breaks the feature build or the integration build, teams will be notified fast. Fast Feedback Loops ensure low cost and better team efficiency.
Please let me know your opinion, I am open for Feedback.