Any IT organization sooner or later has to deal with such thing as Continuous Delivery (CD). They realize that there are various environments such as development, QA, support, UAT, production, etc. and there are a number of different systems working in those environments. At some point managing all that stuff manually becomes just impossible and should be automated. There is a plenty of available tools on the market allowing you to automate build and deploy processes. This is a very common case when different tools are used for different applications depending on the underlying technologies of those applications. In time, when the entire infrastructure gets larger, that zoo of different environments, servers, different versions of applications and continuous delivery tools turns to be a nightmare. I know one organization with a pretty large infrastructure where nobody could draw a diagram of their environments. Another guy from the same company told me that it was just impossible to represent it on a peace of paper in two dimensions and it probably would be possible to do that in 3D or better 4D environment :)
So, it would be nice to have a system which allows you to organize and put together all pieces of your infrastructure, to setup, to control and to monitor them. And such systems exist. In this post I'm going to focus on one of them. This is FlexDeploy. This system is pretty new on the market but I believe that because of its concepts and ideas it has good chances to become popular very soon, especially among organizations working with Oracle Fusion Middleware Products. FlexDeploy itself is an ADF application and it is mostly focused on continuous delivery and integration of systems which are built using Oracle Fusion Middleware.
FlexDeploy claims that it doesn't matter how many servers, applications and tools you have. The fundamental theorem of software engineering "We can solve any problem by introducing an extra level of indirection (... except for the problem of too many levels of indirection)" works very well here. There is always some real number of environments in any complicated infrastructure. For example development, build, production, user accepting testing, QA and support. Using this obvious indirection or abstraction any infrastructure can be easily split into these six parts.
On the other hand, there are instances. For example WebLogic 11g domain, WebLogic 12c domain, WebSphere AS, ESB, ADF building server, Oracle DB, GlassFish AS, ODI, etc. All that is instances. Instances of some systems and tools related to different technologies hosting on different servers across the entire infrastructure. This is the second abstraction.
FlexDeploy lets you easily specify for each instance where (in what environment) it works.
Having done that, the topology of your infrastructure can be represented like this:
And there are applications consisting of projects. For each of them we can specify where they are going to be built and where they are going to be deployed. So each project is mapped to a build instance and to some deploy instances. As I mentioned applications consist of projects. For example some Oracle MAF system WorkMuchBetter actually consists of two projects - WorkMuchBetterClient (actually an Oracle MAF mobile application) and WorkMuchBetterBackEnd (a usual ADF application).
The question is what working horses are actually going to build and deploy projects. There are workflows. FlexDeploy comes up with a very powerful tool for designing build and deploy workflows. A workflow is an orchestration of steps which can be a combination of plugin operations or basic workflow operations such as variable assignment, conditionals, or looping constructs.
Working with the workflow designer in FlexDeploy is similar to working with the task flow designer in Jdeveloper. There is a sheet with a workflow and there is a palette with workflow operations such as While, If, Assign, Wait etc., and a palette with plugin operations. And you can design a workflow just by dragging activities from the palettes and dropping them onto the sheet.
When it comes to plugins, FlexDeploy introduces a wide range of plugins which you can use in your workflows for performing activities related to different technologies. For example fetching source code from SVN or GIT, building an ADF application, deploying application to WebLogic server, running SQL scripts, exporting OSB projects, etc. The full list of supported plugins is available here and a good thing is that this list keeps growing. Basically, if FlexDeploy doesn't have a plugin for a specific task (so far) we can always implement what we need using either Unix Shell plugin or Windows Shell plugin. These plugins let you run any shell script on a corresponding platform.
Prior to FlexDeploy 2.0 you had to install agents on remote servers in order to perform plugin operations on remote servers. An agent is a lightweight Java application responsible for running plugin operations and communicating with the FlexDeploy server. The upcoming FlexDeploy 2.0 uses agentless technology for that just by using ssh connection with a remote server.
So that eliminates managing and monitoring of the agents across your infrastructure making using of FexDeploy much easier.So, it would be nice to have a system which allows you to organize and put together all pieces of your infrastructure, to setup, to control and to monitor them. And such systems exist. In this post I'm going to focus on one of them. This is FlexDeploy. This system is pretty new on the market but I believe that because of its concepts and ideas it has good chances to become popular very soon, especially among organizations working with Oracle Fusion Middleware Products. FlexDeploy itself is an ADF application and it is mostly focused on continuous delivery and integration of systems which are built using Oracle Fusion Middleware.
FlexDeploy claims that it doesn't matter how many servers, applications and tools you have. The fundamental theorem of software engineering "We can solve any problem by introducing an extra level of indirection (... except for the problem of too many levels of indirection)" works very well here. There is always some real number of environments in any complicated infrastructure. For example development, build, production, user accepting testing, QA and support. Using this obvious indirection or abstraction any infrastructure can be easily split into these six parts.
On the other hand, there are instances. For example WebLogic 11g domain, WebLogic 12c domain, WebSphere AS, ESB, ADF building server, Oracle DB, GlassFish AS, ODI, etc. All that is instances. Instances of some systems and tools related to different technologies hosting on different servers across the entire infrastructure. This is the second abstraction.
FlexDeploy lets you easily specify for each instance where (in what environment) it works.
And there are applications consisting of projects. For each of them we can specify where they are going to be built and where they are going to be deployed. So each project is mapped to a build instance and to some deploy instances. As I mentioned applications consist of projects. For example some Oracle MAF system WorkMuchBetter actually consists of two projects - WorkMuchBetterClient (actually an Oracle MAF mobile application) and WorkMuchBetterBackEnd (a usual ADF application).
The question is what working horses are actually going to build and deploy projects. There are workflows. FlexDeploy comes up with a very powerful tool for designing build and deploy workflows. A workflow is an orchestration of steps which can be a combination of plugin operations or basic workflow operations such as variable assignment, conditionals, or looping constructs.
As FlexDeploy is considered to be a fully automated solution it certainly allows you to build and deploy applications on a scheduled basis. When a scheduled task is completed there will be a notification email with the task details. For example when a project is built you receive a letter with SVN changes and links to the artifacts produced by the build workflow. That could be, for example, ear or jar files which can come in handy for software developers. Besides scheduling there is a notion of windows. A window is a timeframe which can be specified for a certain environment and it means that deployments within this timeframe are allowed by default. But if deployment happens to be outside the window it should be approved as an exception by some authorized person. Otherwise this deployment will be scheduled for the start of the next available window. For example, deployments to the production environment are allowed at night only, but if there is an urgent requirement to deploy during the day, somebody should approve that.
Basically, FlexDeploy is constantly enriching its functionality implementing new plugins and working on visualization features such as dashboards and diagrams. And may be now the application is pretty young but I think it is going to become a matured continuous delivery system very soon.
It is possible to request a demo or trial version on the Flexagon site and to try it out for yourself. FlexDeploy is an ADF application which requires an application server and a database instance. But the cool thing is that the trial version can be installed on your laptop just in one click and it takes a few minutes. It is going to install on your machine Oracle XE instance and GlasFish server. So, if you are not happy with that may be it would be better to use some kind of a virtual machine for such experiments.
That's it!
