Standing on the shoulders of giants
I have been involved with the foundation since it’s early days when I attended the first London meetup. When I started the hubot-symphony project, I had an account on the public Symphony POD and that was it. Like many open source projects, I started with a selfish purpose, to facilitate moving existing chat bot tools used in my day job onto the Symphony platform as part of evaluating Symphony. Building software to interface with an API without access to the system itself was certainly a challenge for a modern software engineer and I am glad to say the route I took is consigned to history thanks to the Open Developer Platform (ODP) provided by the Foundation. I want to discuss my initial development approach and how that has evolved as the Foundation has matured.
Most developers will be familiar with the distinction between unit and integration testing, in short, whether you test in isolation or co-operation with other pieces of the whole. When you are building something to interact with an existing API it can be tempting to start with a high level integration test but there will usually be several things that can go wrong and fail your test. Think of the textbook example of making a cup of tea, but instead we want to respond to a user’s Symphony message. The Foundation’s API working group is collating a list of example use cases and each one of these is a mixture of common and specific steps. Fortunately, the scope of the hubot-symphony project is quite a bit narrower, for the simplest use cases we just need to send and receive Symphony messages and extract some basic information about the user who sent each message. I took a pragmatic approach using the nock library and the Symphony REST API to spec out the expected HTTP requests/responses for each of the endpoints needed and followed a Test Driven Development approach to implementation. These tests are written using standard JavaScript libraries which are run using NPM. The next step was to automate these tests as I worked towards a version 1 release.
You may have seen badges on various GitHub projects reporting the build status (see image), which are generated by Travis CI, a cloud hosted continuous 
integration service which is free for open source projects. With the addition of a single file to your repository and a few clicks, your code will be built and tested with every commit. Travis CI does not store anything other than the status of your build and the console output so there are a variety of other services which are designed to either trigger on commit or receive data as part of your automated build. We use several of these services which as a JavaScript novice have been very helpful in improving code quality as well as satisfying the licensing obligations of a foundation project, all of which are free for open source projects. Check out the foundation wiki for more detail of the various services in use within the Foundation, both for Node.js and other languages.
Now, as the project evolves, these quality metrics are visible not just to the project team but also to any current or prospective users which is important in a corporate environment. At this point we’re ready to actually release some code. NPM acts as the centralised artifact registry for Node.js projects so the release process involves creating a GitHub release and publishing to NPM.
This is fully automated by requiring commits to adhere to the semantic versioning concept of defining your changes according to their scope and providing human readable documentation of the change with your commit. The semantic-release project takes this commit data to produce release notes and perform the NPM publish step. With this automation step we can guarantee that each release is fully reproducible as it’s performed by Travis CI and any change which is merged into the master branch and does not break any tests will be released. As a developer this means there’s no build recipe to follow, I can just make my changes and forget about the rest.
With the launch of the Open Developer Platform it became much easier to test and develop the project, and the project team now has access to individual user accounts on the Foundation Developer POD as well as bot accounts which can be used for integration and exploratory testing. If you join the #hubot-symphony room you may find our bot mozart online!
The end result is a software development lifecycle which does not intrude on development and gives both the project team and users a level of transparency and confidence that is hard to beat. If you’re aware of any automation tools that can raise the bar even higher, please let me know in the comments.
Stay tuned for more updates! Want the opportunity to develop a bot, app or integration for the Symphony platform? Join the Innovate 2017 Hackathon on October 3 and show us your skills! Click here to learn more.
