Motus Research Platform Provenance
BSC’s Senior Director, Data Science and Technology, Dr Denis Lepage, Principal Investigator of the CANARIE project and lead programmer, is final authority on all web application, R packages and API software releases. Our lead management team, including Dr Tara Crewe (Senior Scientist, BSC), Stuart Mackenzie (Project Manager, BSC), Dr Phil Taylor (Professor, Acadia University), as well as our software development and user support team will also provide guidance, testing and direction.
What validation procedures would be completed prior to release?
The entire development team meets once a week to review ongoing issues and discuss priorities for development. Any issues that arise at any point of the development cycle are reported to an issue tracker, delegated as needed and discussed during the weekly meetings when necessary. Priorities for team members and software release schedules are decided by the Project PI and Lead Software Developer (Lepage) based on the most up to date version of our work plan and ongoing feedback from staff, our management team and users.
All development is made by programmers in their local environment using GIT software tracking tools, tested locally, and shared regularly with the master development branch (usually daily). We also rely on open-source software throughout the development to help identify potential code issues, including Integrated Development Environments (IDE) such as Eclipse, Netbeans, R Studio, as well as Apache Ant, Spotbugs and rOxygen. We maintain 2 separate development branches (sandbox and beta), and distinct branches for each final release (7 versions released so far). For web applications, including server API’s, as well as for database applications (queries and stored procedures), we have a sandboxed environment where all releases are staged and tested on our server. Once new features have been sufficiently tested by developers and staff within the sandbox, they are transferred into a new beta branch and published on the beta web server. The beta web server is operating with the main Motus database, so any changes to the data are tested under the same conditions as the main server, to discover any bugs or problems. The introduction of new features is usually subject to an extensive testing phase, done by our staff and closest collaborators, while looking at items such as interface usability, integrity of the data generated, and scalability of operations for more intensive use. Staff also use the beta branch as part of their regular operations as much as possible for further testing. When all new features in the beta branch are deemed operational, we transfer the software into the main live release branch and publish to the main server.
Minor bug fixes that are discovered following the release of the main branch are usually made within the most recent beta branch, tested again, and then deployed to the live server within a short time frame, depending on the complexity and severity of the issue. Any bugs and feature requests are tracked within github.com issue tracker, and assigned to the most appropriate staff. One of our staff (data analyst, whom interacts most regularly with researchers) is responsible for ensuring that all relevant issues raised by researchers and staff are submitted into github. Another staff (programmer) is responsible for ensuring that all issues are being assigned and resolved appropriately, in consultation with the team during our weekly meeting if necessary.
Features that require more advanced CPU usage are subject to load testing to ensure appropriate responsiveness in our sandbox environment before they are released to our live environment. This includes database aggregate queries that can produce summarized results used in visualizations and data exploration tools or data access through the API. To increase response time, many of results of analytical processes are stored in cached tables, and the processes for generating those caches are carefully evaluated for response time and CPU load.
While we will advise and influence the development of CTT receivers and operations, CTT will be responsible for software maintenance as part of their own operations. CTT has a strong expertise in cellular communications, and all of their units will have onboard connectivity, allowing for firmware upgrades as needed.
R packages are also being developed using github. We generally maintain a master branch for official releases, and a staging branch where new features are being developed and tested. R packages already have well-established standards and requirements for release, and tools to ensure conformity (e.g. roxygen package, R Studio). Prior testing or staging of branches is done by our team and close collaborators, including for instance testing new features of the sandbox or beta API branches that deliver data to the Motus package users.
What documents would be provided as part of the release package?
For our web applications, which are hosted rather than desktop applications, we maintain online instruction and documentation pages on the Motus web site, and update them as part of the software updates. These include instructions and procedures for registering and deploying tags and sensors, managing projects, metadata and data through the web interface, frequently asked questions related to data flow and use, etc.
API applications will also have their own documentation hosted on the Motus web site, with explanation of the entry points, functionalities, parameters, expected outputs, etc. The direct interactions with the API are currently limited primarily to developers, including those of our partners, and so not exposed to our research users.
Instructions for the SensorGnome operation are made available through the SensorGnome web site, and will be updated as part of any software release. The SensorGnome site will also contain updated information and instructions on how to install and operate the infrastructure that supports the sensors and antennas (e.g. material and equipments to use, step-by-step instructions for setting up the sensors, standards to follow regarding bearings or other types of measurements needed during installation). We will also provide instructions (or access to resources) for users of Lotek and CTT tags and receivers, including updated instructions on how to register and deploy tags and receivers.
R packages have well established guidelines for developing documentation, and those are embedded within the package itself, and made available to users through the R application. We have also developed a
How would you deal with upgrades / patches to third party software packages that you might use?
Almost all of our development is based on industry-standard technologies, software and frameworks that are well established and evolving in a coordinated way (e.g. Java, C++, Apache commons libraries, JQuery, JSON, KML, SQL Server, Google Map API, MySQL, SQLite, Tomcat), with only limited reliance on external third party packages, which limits our exposure to unplanned changes. We schedule down time to apply necessary server patches at times that minimize disruptions for our users whenever possible.
As we are continuing to grow and rely more on external collaborators, most of the impacts will occur through required changes in the API specifications, which are expected to happen in a coordinated way and with sufficient planning. We will continue to work closely with our collaborators (e.g. CTT & Lotek) to ensure that we can coordinate any changes that may have an impact on our operations.