I recently wrote about my experience building a time tracking app using Test Driven Development and Continuous Integration. It generated some questions about the tools I use and how I use them, which is fantastic: I’d rather take part in a conversation than a monologue, so thank you to all who pinged me on email or LinkedIn. Your questions and my answers are below.
Q. “Which platform are you using to build your app?”
The app is developed with Ruby on Rails with MySQL. MySQL is a workhorse, but may be a bit out of fashion now, since as a relational database it’s difficult to scale it horizontally. My colleagues working in the industry will know that today’s web apps trend toward distributed microservices and scalable distributed databases. However, for me, MySQL is easy to use and at this time, I’m most familiar with it.
Ruby on Rails also provides a number of advantages when developing an app. It is a full server-side web application framework. There is also a healthy ecosystem of additional libraries and modules supporting it called Gems. Out of the box Rails provides your app with an API. That means UI can be completely decoupled and converted to a simple web app, a mobile app or both at any time. The Rails framework is built on Ruby which is loosely similar to python. Given my familiarity with python as an Object Orientated language, it seemed the best choice for now.
Q. “How did you setup your test framework?”
The next step to getting this app off the ground was getting an automated test framework in place. I found the RSPEC and Capybara Gems (Rails addins), which allow for automated testing of all Unit, API and UI tests.
Capybara is especially powerful, as you can mimic the user journey through the app, very much like Selenium. Unlike Selenium though, it can’t mimic the behaviour of a specific web browser, so it’s not bulletproof as acceptance testing. It does integrate directly into RSPEC though, which means there aren’t multiple test frameworks to manage.
The syntax of Capybara is very behavior driven for acceptance testing, ie;
Scenario: <Describe the Scenario>
- Visit <some page>
- When I <do something>
- Within <parameters or session x>
- Expect <something to happen>
All tests can be run from the CLI with a single command, to give quite detailed reporting. There are also addon Gems which provide more detailed test metrics and reports and test coverage. A single command means all tests can be triggered by code commit. It returns success or fail, so you can easily prevent failing code commits to your main branch.
Q. “Did you use the cloud or local storage while you were building the app?”
The next step was deciding where to keep the source assets. It isn’t just application code: there will be configurations for supporting systems as well as orchestration recipes for server instances, networking and build scripts.
All of this is code, and it should be tracked and maintained as code. So what to use: cloud or local?
Git was the logical choice, it maintains local copies of repositories and syncs to a central remote. There are a few cloud services for Git which provide integration, but I’m wary of using black-box services. For now it’s in AWS CodeCommit because it’s free, simple and is a no frills repository. It does provide for event triggers, so when code is pushed, it can tell the Continuous Integration platform to run the pipeline. As my infrastructure is already in AWS, I may move this somewhere else in the near term to get some separation and (hopefully) fault tolerance.
Q. “Which platform do you use for Continuous Integration?
Jenkins is the Continuous Integration (CI) platform and is more or less the backbone of the software delivery pipeline. I can’t say it’s perfect. There have been some problems. Still, it works well enough for now.
What Jenkins does do well is help build a workflow that guarantees committed code is tested against the same environment every time. As I mentioned in Part 1, that’s very important to me.
It also has pretty good reporting through plugins that track all commits and subsequent testing.
Given that Jenkins could run anywhere, I needed a very loose coupling between the main code repository and Jenkins. AWS Simple Queue Service (SQS) came to the rescue. It’s a messaging queue which can transmit an event and a small amount of data between two independent components. A successful code commit places notification on the queue, which then Jenkins polls and receives, which triggers the CI workflow. Jenkins can also trigger orchestration/deployment tools to get a successful and fully tested build into production, without any intervention at all.
That doesn’t quite cover all of the questions I’ve been getting. Not by a longshot. Still, I hope this gives you some food for thought about how to get started with building your own app in an age of agile development. I should have another update soon. In the meantime, keep sending your comments and questions!
