TIBant™ v2 has just been released and for us, it’s very special. It’s not special because of any particular new feature within TIBant itself; it’s special because of how it has been released.

For a while now (see item 4) we’ve been students and advocates of continuous delivery and its sometimes scary cousin, continuous deployment, and it’s about time we started taking our own advice for our current projects. This is exactly what we have done with TIBant. TIBant was released using a continuous deployment approach, with commits to the code repository triggering a series of dependant Jenkins Jobs that run automated tests, create the TIBant zip files, publish them to an Ivy repository, upload them to Assembla and then post a notice on our website. All of it is automated; it’s been quite an experience.

What this Means for Users

Going forward, each change committed by any contributor will be released as a new version of TIBant (if it passes all the tests). We know this will result in rapidly increasing version numbers, but we also know it means you won’t have to wait for us to get around to making a release. When a new feature is implemented or a defect fixed, you’ll have access to it almost straight away.

In terms of the version numbers, we wanted a scheme that was predictable, not subjective. This gave us to two options: date-based version numbers or an integer; we decided to go for the latter.

To make this work, we needed a simple and effective way to let you know which versions break backwards compatibility. We decided that the best way to do this is to apply the compatible change pattern and not break backwards compatibility. Instead we will use versioning and deprecation techniques to handle what would otherwise have been a breaking change. The other reason we chose this approach is that a breaking change introduces technical debt into the build scripts of every TIBant user; you would each need to go and change your scripts when you want to upgrade. We’ve all got enough technical debt as it is and we felt it would be selfish of us to intentionally add to yours.

All of this simply means that you should no longer concern yourself about what version of TIBant you are using. We don’t expect or recommend that you try to keep up with our release cycle. Instead of version numbers you should focus on the closed defects and implemented features list and use it to decide if and when you need to upgrade.

Lastly and probably most importantly, because the releases are automated, if you find and fix a defect in TIBant, rather than sending us the fix, waiting for it to be incorporated into the code and then waiting for it to be released, you can join the project, add your change (and tests for it) into the source control and then just upgrade to the new version of TIBant that your change creates.

What this Means for Contributors

You are now empowered to make releases. Every time you push your changes to the source repository, the only thing stopping bugs from reaching the users are the automated tests. The `pre-commit`, `run-uat-tests` and `run-dist-tests` Ant targets are your friends. Make lots of small changes and push them regularly; yes there will be lots of releases, but it means that users get the benefit of the changes sooner, even if the benefit is very small.

Test-Driven Development

When you are working on a new feature or fixing a defect, make sure you create tests for it first (I know I haven’t been following this as much as I should). Use the tests to encode your requirements and then do just enough coding (i.e., don’t overengineer) to make the new tests pass. When the tests pass, push.

`dev` URI

For new macros, use the `org.windyroad.tibant.dev` URI; commit often, push often and when you are ready, move it to the `org.windyroad.tibant`. This allows users to have early access to your macro, with the understanding that it’s still in development.

Branch by Abstraction

If you need to rewrite a macro, create a new one using the `dev` URI mentioned above and use an `if` to toggle between the new and old implementation (which is useful for running the old version’s tests against your new version; but be careful not to change to the old tests). When you are done, if the attributes are the same in both versions or the new version’s attributes are backwards compatible, just replace the old version with the new. If the attributes are not backwards compatible (i.e. the old tests break), then add a v2 at the end of the new macro’s name and mark the old macro as deprecated by adding `_Deprecated._ ` to the beginning of its description.

What’s Left to be Done

The CI server doesn’t have a `LOCAL` domain set-up for testing, so the tests for running BW and deploying to administrator are not executed as part of the pipeline. Please be careful when making changes to these macros and use the `run-pending-tests` target if you are.

Thanks

Once again a big thanks goes out to John Menzies at Think Platinum for his contributions to TIBant. But an even bigger thanks goes to Nick Grealy, who has done an awesome job of setting up our CI server. Nick joined Windy Road earlier this year and he has been doing fantastic work ever since. We are really lucky to have someone as good as Nick on board. He’s awesome and he just gets it. Thanks.

Would You Like to do Something Similar?

Are you looking to set up a continuous delivery or continuous deployment pipeline for TIBCO BW based projects? Let us know and we can start to discuss the different ways we can share our expertise with you.