Makers Week 9: Rails Project Greenbook

Thanks to Heroku, our app lives forever now on the web! Visit here to play around!

Image for post
Image for post
source: Pixabay

London, Shoreditch

The 8&9th week at Makers was a long-run of making our own facebook — we call it Greenbook to show support for the environment. While I wrote one article which was published in our series of blog in Medium last week — click here if you want to have a look, I do reserve my spot here to have a more personal reflection at the end of the project.

So here are the break-downs for this two weeks.

  • Build a full-stack Rails app (I reflected on it in my group blog linked above, so here is just a few points about rails testing)
  • Build technical workflows (PR, CI, CD, code quality and testing)
  • Practice team processes simulating a real-world engineer team (standups, retros, sprints, estimating, planning)

So let’s talk about Rails testing first. Last week, I “complained” about its “convention over configuration” and how both convenient and hateful it is. But testing in Rails is another beast. First we all have to admit the importance of testing, without it you have no control and understanding of the behaviour and logic of your app, and no protection against regression within your app upon modification. Previous using Sinatra — another framework similar to Rails but more flexible, I was using Rspec for unit testing and capybara for feature testing. But in Rails, there seems to have include at least another level of Controller Tests, even if I temporarily ignore the need for View Tests (as I already have capybara to test the web workflow).

  • Unit tests, which test some basic behaviour in your models. In Rails it can be seen as the same for Action Models test.
  • Feature tests, which have a syntax for interacting with headless web pages. In Rails it can replace the need for Action Views test.
  • Controller tests, which have some special features for calling controller actions directly from the test and evaluating the resulting integration variables.

So why controller tests troubled me so much? So according to the idea of the test pyramid, which is a term coined by Mike Cohn, the base of the tests is unit tests, which are very small and focused. On top of the tests is feature tests, which are less and more end-to-end. But controller test sits in between:

  • It’s not unit tests as it usually test the controller and the associated ActiveRecord, and it involves conditional logic.
  • But it is not feature test either, as there is no real web flow such as “click” event, even it involves the use of the request/response cycle.

That’s where I found it hard to totally separate with the other two end: unit and feature tests. A snippet of my controller test below, where you can see the test does touch the interaction with ActiveRecord and the request/response cycle, but there’s no real simulation of the web flow.

Even though the project has a good test coverage thanks to unit tests and 9 feature tests, moving on, I hope I could have a better application of controller tests in my next rails project.

So coming back to a bigger question from the above technical detail: how did the team manage the technical workflow?

Here you go!

Image for post
Image for post
An overview of project pipeline

This is really an exciting experiment. As software engineers are not just coders. Putting them into a work environment, they work in teams; they have projects spanning in months; they have an end user to deliver the product to… All this requires a smooth and well-planned pipeline.

I learned two essential concepts at this stage:

Continuous Integration (CI)

— A development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Continuous Delivery (CD)

— A natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button. Continuous Delivery aims to make releases boring, so we can deliver frequently and get fast feedback on what users care about.

What are the benefits?

  • Easier integration (as each change is smaller )
  • More visibility (once pushed, everyone can see your code)
  • Cost saving (early identification of bugs)
  • More consistency (as each push is a smaller change to the last one)
  • Rapid delivery cycle ( fewer integration issues)

I believe there is much more than what I listed above. But simply looking at these points, and relating to my experience during the project, I’m already fully onboard.

Talking about CI, one important tool the team used is Travis CI. There was hesitation between Travis CI and Jenkins which I know is equivalent, if not more popular. However, while Jenkins is open-source and free, it has no hosted solution, and it seems to be left for the project team maintain the code. But Travis lives on cloud, and is maintained by its own team. So even Travis has limited free plan (sufficient for our project size), it’s our final choice in the end.

Unfortunately, I didn’t get to experiment with CD a lot other than the automatic deployment on Heroku. I would definitely be keen to try Canary release or Blue-green deployment next project if possible.

Finally, it’s about team process. What the team adopted is using sprints.

So here is what we do in one (two-day) sprint:

  • Planning session

— Estimation (Using T-shirt size: S=> 0.5 d,M=> 1d,L=>2 d, XL..)

— Breaking spec into user stories (with AC)

Image for post
Image for post
Breaking down stories into refined cards
  • Follow the trello planning workflow (To do-In Progress — Blocked- In Review- Done-In Production)
Image for post
Image for post
An overview of Trello workflow
  • Daily standup

— Where I was

— Where I will be

— Where blocked me

  • Retro

— What goes well

— What goes unwell

— What to change

It’s quite a long process, but I’m happy and proud of what I achieved here. If there’s anything to improve (obviously there’s a lot), I would like to revise the estimation precision in every planning session based on the last estimation vs. production time.

So, that’s all for this week. Looking forward to seeing you next week, and an early Merry Christmas!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store