The Project

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.

The Challenge

There was no design, only a needed result with a spreadsheet that listed all of the required assets. 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.

How was this possible?

Using our design services, Ext JS 4, our existing client and server frameworks, and our existing build infrastructure and process.

Design Services

Whether high resolution wireframes or low resolution paper mock-ups, having a plan and a mutually shared goal is one of the first steps of having a successful project.

Ext JS 4

Ext JS features high performance, customizable UI widgets and a well-designed and extensible component model. Ext JS is a great solution for anybody looking to build applications with web standards.

AppContinuum

For generating client (Sencha Touch/Ext JS 4), server (Spring RESTful), and database (MS SQL/MySQL/MongoDB) projects and automatically configuring them to be built on a continuous integration (Jenkins) server, which also handles deployment automation.

HTML5 Robot

A tool for HTML5 test automation, which allows you to drive a web browser like a human being so that you can fully automate the testing of your client application.

Java Spring

The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform. A key element of Spring is infrastructural support at the application level: Spring focuses on the "plumbing" of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.

Af Gradle

Our core build framework which along with handling server-side compilation, unit testing, integration testing, and database versioning also handles fully automating the process of compiling a Sencha Touch application into native iOS, Android, and Windows mobile applications. For a detailed explanation of the Sencha build process see this. As for Ext JS, this framework handles packaging, managing, and optimizing Ext JS based web applications.

Design Services

What are we building, what are the screens supposed to look like, what happens when I press this button, is this what the client wants?

Without the answers to these basic questions prior to starting a software project, especially if you are using multiple developers, you are going to be in for a lot of re-work. It is more cost effective to draw a screen on a napkin (or by some other lightweight mechanism) and discuss its function with the client, than it is for you to build an entire three-tier system and hope for the best. It is also important to have an actionable plan which is flexible, and gives all project members a common and understood goal to work towards.

The Broadway Automation project was more about function over form, so high resolution wireframes would have been unnecessary. For this reason we used a lightweight approach to get something visual in the hands of the end-users as soon as possible. This allowed us to discuss and walkthrough the operation of the system from a visual (end-user) perspective, and easily make adjustments. The end result was a plan that all project members, from developer to end-user, could understand.

Target Architecture

The target architecture was significantly shaped by the following given requirements:

1. The system must work with the current system used for storing and managing client assets, which was a Subversion SCM server.
2. The system must be able to notify the job on the Jenkins continuous integration server, that a particular client configuration needs to be built.
3. The system must allow existing corporate (LDAP) users to login with their credentials, as long as they are a part of a particular Active Directory group.

The resulting architecture was a web server that hosted an Ext JS based front-end that talked with a RESTful Spring based backend, which used LDAP for authentication and that interacted with Subversion.

Release Management Strategy

We went with the four environment approach based on the following specifics needs:

1. Development – This is where developers do their work on their local machines.
2. Staging – In order for code to make it to this environment unit and integration test must first pass, which results in the system being fully deployed. Once deployed the test automation suite runs against the fully deployed system using the client application as run in the web browser. The purpose of this environment is automation.
3. Quality Assurance – In order code to make it to this environment the test automation suite must have passed. The purpose of this environment is to be identical to production for the purposes of human acceptance testing.
4. Production – In order for code to make it to this environment a human being must approve the state of the system in QA. This is the end-user facing environment.

The reason for the different environments is ultimately to prevent deploying broken code to production, while allowing developers to nearly instantly be able to see there changes in a fully deployed environment. Developers and Testers can freely do their jobs without fear of breaking and/or effecting the production environment.

The following diagram describes the build process:

1. On change to either the server or client project, the corresponding client or server job is run on the continuous integration server.
   • The client job packages the Ext JS application as a web application
   • The server job runs unit tests, integration tests, and then packages the application as a web application
2. Deployment to the staging environment is then initiated, which includes:
   • Deploying the client and server web applications to the application server
   • Running the Test Automation Suite against the deployed client application through a web browser
3. Deployment to the QA environment is run every morning or manually if needed.
   • QA consists of the same components as staging, with the exception that the Test Automation is not run here
   • This is done to prevent deploying broken code to QA
4. Deployment to the production environment must be initiated manually.
   • Production consists of the same components as QA
   • This again is done to prevent deploying broken code to production

Working with the Ext JS 4 Client

In terms of the development environment, our preference is Eclipse for the following reasons:

• It has a decent JavaScript editor which allows us to ignore framework directories like the one for touch as part of compilation. This saves a lot of time.
• Eclipse comes with integrations for SCM such as SVN, so we can directly work with version control in the IDE.
• Eclipse comes with an Ant plugin which we used to wrap the various calls to Af Gradle to package and test the application in the web browser
• Eclipse lets us run the Ext JS application on a web server out of the IDE
• Eclipse is our Java Spring development environment as well.

Working with the Java Spring Server

The Java Spring environment is fairly straightforward, and something that has been in practice for a very long time. From an Eclipse perspective it is a “Dynamic Web Project” with the various Spring libraries in WebContent/libs, where you then setup Controllers as JSON based RESTful endpoints. Through Af Gradle the dependency management and general build/packaging project as also easily handled. The architecture for this mid-tier is split into the following:

• REST Controller – A RESTful endpoint that accepts JSON input and returns JSON output for the purposes of web services. Also handles authenticating requests through Spring Security.
• Service – The business logic layer that interacts with the Controller through DTOs and DAO layer through mapped entities. Dozer is used to easily map domain information into an optimized format that only contains exactly what the particular client call needs for performance purposes.
• DAO – The layer used for direct interaction with the SCM server through SVN Kit. The purpose of using this architecture was so that if needed the underlying SCM could be changed, or replaced with a database entirely.
• Subversion (SCM) – The layer where data is persistently stored and versioned.

The application deployment format is WAR, in which the same WAR is used (in different versions) in each environment. This means that configuration information such as the location and credentials of the database is stored externally on the server. The advantage of doing this is that the same application binary is in every environment with no modifications, so there is no room for human or modification related errors. Something not working correctly that is working in other environments? It is a configuration (or related data) issue.

TIP: An important part of the server-side development process is unit and integration testing. This allows the developer to fully vet created web service endpoints in a realistic environment prior to making them available to the native clients. These tests then ensure that overtime as the application changes the functionality is not broken, resulting in a more stable overall environment. This is especially important during initial development as things are continually changing at a quick pace. Breaking previously working functionality creates additional work, which is unnecessary considering how easy it is to put the appropriate development practices in place.

Working with HTM5 Robot

The difficulty with HTML5 based web application is that they generate a lot of complex HTML and JavaScript, in which current test automation tools do not have a good way to interact. These tools attempt to interact with components using XPath statements that are several hundred characters in length. These XPath statements are not only unreadable to humans; they are also prone to breaking the next time the page is loaded.

HTML5 Robot solves the problems with unreadable and unmaintainable XPath and CSS Selector statements by using a methodology for getting an HTML component, where you simply specify what you want, like a button, and how to find it, like by the text on that button. You then can perform a list of predefined activities with the component once it is located, such as to type text into it, click it, or drag and drop it.

In particular the Gwen Language and the Gwen IDE of HTML5 Robot provide a human-style language means of writing tests to run against a Sencha Touch based application. We used the Gwen IDE to walkthrough the functionality of every screen, and then set these tests to be run after any deployment to the staging environment. The result was a human style regression test run with every code change to the system, in order to ensure that new functionality was not breaking and/or unintentionally affecting existing functionality from and end-user perspective.

Ready to make our process work for you?

Contact AppFoundation