What is Scout Talent software?
Here at Scout Talent, we consider ourselves very lucky to have such a broad range of users across several industries. We love connecting with the many stakeholders who are involved in their company’s talent acquisition solutions.
We’ve spent most of this year knee-deep in an upgrade project that most of our users normally wouldn’t hear about. We wanted to share our reflections on an expansive software project we’ve been working on. This will give you a peek into the work we do behind the scenes at Scout to keep our software suite innovative.
Under the hood, our software operates exactly as you would expect a modular and open product suite to operate. Its infrastructure is hosted by Amazon Web Services (AWS; a scalable cloud computing service), and it uses React (an open-source interface library) and MySQL (an open-source relational database management system) as its technologies. Ruby on Rails (RoR), is the framework that ties it all together.
What is Ruby on Rails (RoR)?
If you’re not from a technology background, you may be wondering why you’re reading about the nuts and bolts of our software. To give you insight into our software back-end, we’ll be exploring RoR (the framework that ties it all together), and what we found when we upgraded to the newest version.
Before diving in, it’s best to explore what RoR actually means and how it functions. Rails is a programming framework, while Ruby is the underlying programming language. Thinking of it in simpler terms, Rails is the house, while Ruby is the bricks. Each individual brick contributes to the framework of the house as a whole, and allows you to build and upgrade as time goes on.
Long story short, RoR is an extremely popular open-source framework. Some of the largest companies in the world use it (think Shopify, Airbnb, and Kickstarter, to name a few). Scout also uses RoR, and we do so for many reasons. It simplifies the development processes by providing conventions on repetitive tasks (such as retrieving and storing data from our database). The simplicity of these conventions lets us concentrate on solving business problems, not technical problems.
Why did we have to upgrade Ruby on Rails?
Some of Scout Talent’s software has been around for over ten years. During this time, it has helped companies small and large transform their recruitment process and secure the best talent.
As technology evolves so quickly, we’ve had to be strategic about how we’ve upgraded our underlying software over the years. When new RoR versions are released and improvements are implemented, software becomes more disconnected from the latest version of the framework. The longer you run an old version of RoR, the less opportunity you have to take advantage of its new improvements. We wanted to continue to provide the best possible experience for users of our software suite.
We knew that upgrading this year was going to provide better ways of handling business logic behind the scenes, allow us to continue prioritising security and stability, and give us a big boost in our quest for performance improvement.
While these benefits give great incentive to upgrade, the reality is that it’s not that simple. It’s important to find the right balance between time investment, platform maintenance, change management plans, and ensuring users aren’t negatively impacted during the upgrade.
Upgrading in this way gave us better ways of handling business logic internally, helped us prioritise security, improve performance, and ensure stability for Scout tech users.
What was our process?
Here’s where we jump into the nuts and bolts of it.
There were many steps in the overall process. The first was to replicate and upgrade the codebase to work with the latest version of Ruby on Rails. This means we could test how :Recruit performed with this version of the software. To do this, we created a new server to run the upgraded version.
Once the software was stable, we then created a load balancer in AWS. A load balancer is a device or process by which traffic (i.e. web requests) is diverted to different servers. Think of it like a railroad switch that guides requests down diverging paths to prioritise speed and efficiency.
Then we created a method to split the traffic between the existing version of :Recruit (that clients were currently using) and the newer, upgraded version of :Recruit. This way we could test the upgrade with minimal disruption.
At this point, it’s all about testing! We spent a lot of time testing this upgrade in our staging environment (the sandbox where we find flaws and errors, and to challenge the system performance before going live). We identified issues in this environment by both automated and manual testing processes. Our goal was to fix any issues while continuing to add improvements.
Once we were satisfied with the staging environment tests, we moved to a live environment and switched our beta users over to work on our upgraded version of :Recruit. These beta users consisted of our internal teams and divisions, all of whom use :Recruit daily. We observed them, the system, and our monitoring tools to make sure there were no kinks to iron out. When we were satisfied that we’d fixed all issues, we moved all users of :Recruit to the new server.
Where are we now?
With all traffic now on the new codebase, we’ve seen a performance increase of approximately 20% across :Recruit. The upgrade has allowed us to transition to a new way of handling background jobs. Users will feel the impact of improved email sending, report generation, integration performance, and much more.
We also took this opportunity to improve our system-wide methods to roll out new features quickly, painlessly, and seamlessly. This will mean that you can continue to recruit the best talent for your organisation with zero disruption.
Did it all go off without a hitch? Not entirely. We’re a pragmatic bunch, and while no framework upgrade is flawless, it was an overall win with some great learning outcomes.
Would we have liked it to have been a faster process? Of course! We have so many great things on the roadmap for this year and we’re itching to get to them.
Overall, we’re ecstatic with how our upgrade went. While these upgrades are stressful, support from our internal teams and some amazing clients made this a positive roll-out.
