Sunday, September 11, 2016

Easy SOA releases with JGitFlow

If you use GIT as your source control system and if you use maven, the jgit-flow plugin is a massive time-saver, especially when we release a slightly large application with multiple modules (Each with it's own pom file). 

Two steps: 
 mvn clean external.atlassian.jgitflow:jgitflow-maven-plug in:release-start
and 
 mvn clean external.atlassian.jgitflow:jgitflow-maven-plug in:release-start

do the job. 

The above sequence basically updates the pom file versions to a release version (e.g. from 1.0-SNAPSHOT to 1.0, merges the development branch changes to the master branch, and sets the pom versions in the development branch to the next snapshot 1.1-SNAPSHOT)

If you have an application with multiple projects/modules, all of them can be released in one go (such as my application here that contains two modules)

Of course, there are some peculiarities when SOA Composite projects are involved. 
e.g. the oracle-soa-plugin maven plugin insists on 'deploying' the composite and running tests at the same time - so you need to keep a SOA server running and supply the serverUrl, username and password properties. (keep the properties names different - see sar-common pom for example names) just so they don't clash with the jgitflow username and password properties. 

I avoid this by simply using a private-public key pair to interact with github which saves time and avoids the above property name clash. 

Of course, there are ways to not have the oracle soa plugin insist on deployment when creating a release, but that is a post for a later day!. 




Saturday, September 03, 2016

Test Driven SOA - citrus for powerful SOA test coverage

Reading parts of Test-Driven Development for Embedded C" by James W. Grenning inspired me to take another look at this area and look for something new,  fresh and powerful for use in the SOA world. 

I don't think we need much convincing on the importance of  automated test coverage (if someone does, please read the first chapter of the book mentioned above, especially the section on "Physics of TDD" that tries to quantify the high long-term costs of "Debug later programming" - the nemesis of TDD)

A very simple application with a SOA composite project and Tests project can be found here: https://github.com/jvsingh/SOATestingWithCitrus

Although the test in this is just a simple SOAP request, what I am interested in are the features that citrus has to offer that can help create a solid battery of tests. 

  • Tests can be specified in Java or XML or a combination of both
  • A number of test utilities are inbuilt - including things like database access, JMS,mock SOAP endpoints (static responses), complex assertions - and these can be used to write complex setup and teardown routines


I will leave the reader to peruse the code on github but this shows the most important pieces of config in my test project:



  • To build+deploy+test, after making sure your SOA server is running, just run "mvn integration-test" from the application level (provide serverUrl, user and password in the SOAComposite pom or from the environment e.g. -serverUrl=http://soahost:port)
  • To only run the integration tests, just run "mvn integration-test" from the SOAApplication/SOACompositeTests level.

This is all neat and CI ready!