In the “Developer Interview” series we talk to developers from some of the companies using Semaphore to find out how they work, and share their insights with you. This time we had the pleasure of talking , a Portuguese company that has two completely bootstraped products behind them.
Tell us about your role and responsibilities at RUPEAL.
I’ve been a team leader for a couple of years. I work together with the team on building new features, planning our product’s architecture and improving our development process. When I moved to the company, I started doing Ruby on Rails on InvoiceXpress, an online invoicing system. Three years later, I am now bootstrapping again with a new product: ClanHR.
What does your product design and development workflow for ClanHR look like? Any important lessons from the past you’re applying to your new product?
We have a product owner that does market research and builds proper specs. We use marvelapp to build interactive mockups, and we show them to clients for product fit. Next, our designer builds mockups of the features and iterates on them until we are happy with it. The designer is proficient in building ReactJS/HTML/SasS applications, and she can build a visual representation of the features in ReactJS. This means that we should have proper specs and already available pages and React components when the features get to the developers. The developers just need to add functionality.
All code is on GitHub, and all changes must be made via pull requests. When a pull request is available, the entire team must review it and OK it. As soon as the branch is created, Semaphore steps into action: it bootstraps the app, checks dependencies, runs the tests, and generates a package. If everything is working, the pull request will be marked as good to merge.
When we merge the pull request, Semaphore automatically deploys the master version to the staging environment. This means that we get to staging very quickly. This is important because the product owner and the designer can fine-tune the features quickly, and it saves us time spent on deploying.
This is in contrast with our other product. Due to several legacy issues we can’t be this agile, and end up spending a lot of time waiting around for things to happen.
Is your team doing TDD or BDD? How would you describe your role of Lead Code Detonator in the process of product development?
We mostly do TDD. When the developers get a feature they need to implement, we usually team up to think things through together. Even if it’s just going to be one developer to implement the feature, this analysis phase really boosts our productivity. Next, the developer starts coding. We are working with Clojure, and have a very fast workflow with fast unit tests. We implement endpoints on the services without booting a server, we just create tests and scenarios until we have the server side of the feature done.
The last step is to go to the frontend and connect everything.
What tools and guidelines do you use to write tests across your application stack?
Because we rely so much on TDD, our tests’ feedback cycle needs to be pretty fast. When we are testing code with dependencies like the database, we create a gateway for the actual database, and an in-memory implementation that mimics the database gateway. We then implement and test this very fast environment again. However, we also want to test all that we are doing against the database gateway. We can do that on our development machines, but usually we leave that to Semaphore. When we push, Semaphore runs the tests two times, one for each gateway.
We also try to focus on gateway-less scenarios. Using functional programming and focusing on pure functions allows us to build tests that just check data and have no dependencies.
All services are tested as a unit, and they don’t communicate with other services during the test process. However, we use Nightwatch to test features on the frontend. These are very high-level tests that touch all parts of the application: the frontend, services and the database. They are very slow, so we try to keep them small and only create scenarios for key workflows in the application.
You mentioned to us that your full tests went down from 40 minutes on our machines to 15 minutes on Semaphore. How did this happen?
At one point, our full test suite for InvoiceXpress would take about 40 minutes to complete. This was on our development machines, and we started running the full suite only before merging a branch. However, on Semaphore, the full build took 30 minutes to do the same! And then we enabled parallel execution and split the unit tests from the Cucumber tests, and the full suite took 15 minutes.
“The feedback cycle improved so much that we started pushing to master to verify that the tests were passing.”
How does Semaphore help you achieve your goals?
Semaphore is very easy to configure, and also very powerful. It enables us to easily implement a continuous delivery process without having to worry much about the way to implement it. Any team member, even the non-programmers, can make changes, and as soon as the branch is merged, it will take only a couple of minutes for them to see their changes live.
The support is also great and fast, and always tries to come up with solutions for our weird ideas. The whole company feels that Semaphore is a valuable business partner.