The Broadway Automation Tool project was to create a web portal for centrally managing mobile application text, graphical, and configuration assets for a mobile application called Broadway. Broadway was a vendor specific configurable mobile application, so that every vendor could have their own customized mobile application to fit their specific needs. There was an immediate need for this tool, as the development staff was currently having to manually do configurations for every build for every client. Another objective was to make it easy enough for the marketing/graphics staff to be able to do this themselves without needing a developer.
There was no design, only a needed result, a spreadsheet that listed all of the required assets, and technical requirements that mandated that the system interface with the existing Subversion and Jenkins infrastructure. We used this as our starting point and generated a series of low resolution wireframes that walked the enduser through the configuration process. We went over the wireframes with the business, talked through the scenarios, and made adjustments where needed. Once we had agreement over the wireframes, we used those drawings along with gathered use cases and detailed functional needs to generate a project plan that broke work up into actionable tasks.
Architecturally the resulting system was best described as web portal, however consisting of the standard two components with the data layer being slightly different: Front-end for presenting information to the user, a Mid-tier for processing information, and a Data layer for persistently storing information. The front-end was Ext JS because of its rich catalog of available components, along with well established community and history of success. The Mid-tier was Java-Spring because of its enterprise scalability, ease of use, and established best practices. For the data layer the needs were a bit different since technical requirements mandated that we deal with stored information in the existing Subversion infrastructure.
An existing continuous integration and continuous delivery framework and infrastructure allowed us to quickly standup and run the initial project, and then execute tasks in order to construct the system. With each weekly demonstration of capability came requested changes and additions, which were prioritized and placed into the different scheduled releases.
Through continuous integration, every change resulted in unit testing, integration, and acceptance testing. Unit testing would verify code at the function level, integration testing would verify server-side functionality from the endpoint level, and acceptance testing would verify system behavior from a user perspective by executing automated tests in the web browser via HTML5 Robot. This allowed us to continually change the overall system while being assured that we were not breaking existing functionality, and the the front-end remained working in all supported web browsers. This level of stability also gave us enough confidence to be able to automatically deploy the system multiple times per day.