Continuous Integration with Tibco BW5

Continuous Integration with Tibco BW5

Posted by

A nice approach to Continuous Integration, using Jenkins, Maven, Nexus, SonarQube and SOAPUI

Continuous integration has never been straightforward when using Tibco products, and due to the unstoppable tendency of  the technology scene towards continuous integration (CI) + continuous delivery (CD), we couldn’t refrain ourselves creating our own CI for Tibco BW5.

From our point of view, a CI system must be able to:

continuous

- Build, deploy and test automatically

- Version Control

- Detect errors between versions, and identify what, where, when and who

- Produce releases automatically or semi-automatically

- Provide a clear status on the different versions of the software

- Send notifications

 

For all of the above to be possible, we considered the best approach would be to make the process seamless to the developer and the CI system. So we re-defined the development, analysis, build, deploy, test, automatisation and release process.

One of the biggest problems we have found working with Tibco BW, across the years, was the dependency resolution, so we knew Maven must be part of the software pack that will implement the solution. Finally, the tools that would help us to model the new processes were:

  • Git: SCM
  • Maven: prototyping, dependency check, build, versioning
  • Nexus: artefacts repository
  • Static code validation: SonarQube + TQube
  • Jenkins: to perform nightly  builds, deploy, test, release and notify
  • SOAPUI: to perform integration tests

                      

- Development process: the developer instantiates a maven archetype of a Tibco BW project, sets the dependencies on the pom.xml, composes the Tibco project and open Tibco Designer using our custom plugin for Maven,

- Analysis process: using our T-Qube plugin for SonarQube, the code will be statically analysed for violations on the methodology defined.

- Build process: gets the latest committed code and, using our custom plugin for Maven, the projlib and ear files including dependencies (jars, libs, etc…), are created.

- Deployment process: using our custom plugin for Maven, the ear file is deployed into administrator and application is started.

- Testing process:  using SOAPUI plugin for Maven, the test suite is executed and if the result is successful, the ear file will be uploaded to Nexus, and a fabulous test report is produced.

 

- Automatisation process: a job must be created in Jenkins, executing the same commands as a developer would do:

  1. Analyse
  2. Build
  3. Deploy
  4. Test

- Release process: we wanted to keep it semi automatic. When a version is ready to release, the Maven release process is manually triggered, and executes the following actions:

  1. Code Tagging
  2. Creation of a new SNAPSHOT
  3. Analysis
  4. Build tagged code
  5. Deploy
  6. Test
  7. Upload artifact to Nexus

Now every time a developer commits code, it’s automatically built, analysed, deployed and tested. If something fails, we know what fails, when the failure started, where the failure is and who introduced that failure. It saves plenty of time when your team is not only distributed into different geographical locations, but also when working in extremely specs changing projects.

Screen Shot 2015-11-24 at 18.17.46

Screen Shot 2015-11-26 at 13.01.42

 

Screen Shot 2015-11-26 at 13.06.25

 

Wanted to know more about this CI model, contact us now!

What is next???

- BW5 to BW6 migration effort estimator, using out TQube.

- Tibco + Docker + Hybrid cloud etc…

Will keep you posted!!

 

SuperUserTeam

2 Comments

  • Williamsi says:

    Hey, thanks for the article.Really thank you! Pagonis

  • Srikanth Reddy K says:

    Hi Sir/Madam,

    I really liked your post, and need to implement it by myself to better understand. Could you please share the scenario step by step or what steps can I follow to get it, please help me… :)

    Thanks,
    Srikanth K

Leave a Reply

Your email address will not be published.