A topic that often comes up in consulting engagements that involve Oracle SOA Suite is migration. Simply put, migration moves a code release – or some of its component – from one environment to another.
When it comes to SOA Composite Applications, one approach I have seen consists in leveraging the revision control system, Subversion (SVN) as an example. In this model, the code is 1) checked out of SVN, 2) configured for the target environment, 3) built or compiled, and 4) deployed to the target environment.
This approach is generally supported by scripts such as Apache ANT scripts. The configuration for the target environment consists in substituting the current properties, URLs, URIs, etc. using tokens substitution as an example. Finally, Oracle provides some basic scripts that can be used to deploy the code to the target environment. This can be automated (partially or completely) using scripts such as Apache ANT, WLST or even basic operating system scripts (e.g. Windows CMD scripts, Linux/Unix shell scripts).
For each environment where the code is migrated, the code is retrieved from the revision control system. Therefore, it can be argued that this process does not migrate the same code from one environment to another. Techniques such as tagging in SVN as an example can ensure that it the same code is though. I have seen this practice done in the Java Enterprise Edition (JEE) world. I never liked it and still do not like it when I see it in the Oracle Fusion Middleware world. Nevertheless, many quality assurance professional disagree with this approach.
It is possible, with very minimal efforts, to migrate the same code so to speak from one environment to another without the need of going back to the revision control system. SOA Suite includes capabilities to export and import any SOA composite application. In addition, the use of configuration plans with the composites will handle the required configuration for the target environment. This very easily addresses the concerns of quality assurance professionals.
When using this approach, the developers will deploy a SOA composite application to the development environment using JDeveloper. When migrating from the development environment to the next environment, testing as an example, the SOA composite application is first exported to a SOA Composite Archive File or simply SAR file. Next, it is imported to the target environment using the corresponding configuration plan. Oracle provides basic Apache ANT scripts to support this process. It is possible to build some pretty sophisticated scripts to export more than one SOA composite applications, and even to automatically import them into the target environment.
As mentioned before going back to the revision control system each time code is migrated is something I have seen used in consulting engagements in both the Java world and the Oracle Fusion Middleware world. In my humble opinion, that does not make it right. Using the import and export approach is a best practice, at least for quality assurance.
I hope this help. If you would like more technical details, feel free to let me know.
Hello Alan, thank you for the post it’s really helpful for me as a developer.
I have a quick question – when migrating a composite from dev to prod, how does composite revision number is managed?
For example, I have version 1.0 in DEV and PRD. For next cycle, we have updated some rules in 1.0 deployed in DEV and would like to move the changes to PRD – Now, if I just export from DEV and deploy in PRD, current running instances in PRD will become stale – how can we overcome this?
Thanks,
Hrushikesh