Fresha

When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.

"Soft" part of our development process is handling with: JIRA (which supports our processes & workflows), Confluence (as a knowledge base) & Slack (not only as a collaboration tool, but also as an integration platform for various bots - ChatOps). We use Slack to ask for optimal peer code reviews, create new test environments, etc. We keep UI/UX designs in InVision .

Regarding Continuous Integration - we've started with something very easy to set up - CircleCI , but with time we're adding more & more complex pipelines - we use Jenkins to configure & run those. It's much more effort, but at some point we had to pay for the flexibility we expected. Our source code version control is Git (which probably doesn't require a rationale these days) and we keep repos in GitHub - since the very beginning & we never considered moving out. Our primary monitoring these days is in New Relic (Ruby & SPA apps) and AppSignal (Elixir apps) - we're considering unifying it in New Relic , but this will require some improvements in Elixir app observability. For error reporting we use Sentry (a very popular choice in this class) & we collect our distributed logs using Logentries (to avoid semi-manual handling here).

We make sure to implement only the functionalities that are specific to our business domain (Beauty & Wellness) & use other services for functionalities we find generic or secondary (they do not make us stand out). We've picked the most stable & popular ones we could find for such purposes: Google Maps (for salon location maps), Mandrill (sending mail notifications), Twilio (sending SMS notifications) or Braintree (for payments).

Initially, all our users accessed the platform using web apps, but at some point mobile was a must, not an option. We've decided to go for relatively unpopular option - share as much of Front-End JavaScript code by bundling React applications on the top of Apache Cordova. This way we didn't have to hire Android/iOS developers & we've simplified testing of our apps. We knew it won't be possible to achieve fully native UI/UX on both platforms (Google Play & iOS App Store), so we've ... decided to design our own look'n'feel, which is not native, but attractive enough to stand out in the eyes of our users. All our Front-End apps are built with Webpack (pretty much an industry standard these days ...) & static-checked with ESLint (we have a locally customized set of rules).

Heroku was a decent choice to start a business, but at some point our platform was too big, too complex & too heterogenic, so Heroku started to be a constraint, not a benefit. First, we've started containerizing our apps with Docker to eliminate "works in my machine" syndrome & uniformize the environment setup. The first orchestration was composed with Docker Compose , but at some point it made sense to move it to Kubernetes. Fortunately, we've made a very good technical decision when starting our work with containers - all the container configuration & provisions HAD (since the beginning) to be done in code (Infrastructure as Code) - we've used Terraform & Ansible for that (correspondingly). This general trend of containerisation was accompanied by another, parallel & equally big project: migrating environments from Heroku to AWS: using Amazon EC2 , Amazon EKS, Amazon S3 & Amazon RDS.

Initially we had just 1 monolithic application with a PostgreSQL database (picked for performance, community & flexibility to work with GIS data), but as we've developed more features, it was clear that some stuff is relatively independent from the rest of the platform - it made sense to split the application into loosely coupled, asynchronously communicated services. As a communication broker we've used RabbitMQ (wrapped in our custom, ProtoBuff-based wrapper). To reduce some excessive inter-process (& inter-dyno) communication, we've applied Redis as a tool to keep short-lived, not-persistent information (but not as a cheap caching workaround for any kind of performance issues ;>).

Another major decision was to adopt Elixir and Phoenix Framework - the DX (Developer eXperience) is pretty similar to what we know from RoR, but this tech is running on the top of rock-solid Erlang platform which is powering planet-scale telecom solutions for 20+ years. So we're getting pretty much the best from both worlds: minimum friction & smart conventions that eliminate the excessive boilerplate AND highly concurrent EVM (Erlang's Virtual Machine) that makes all the scalability problems vanish. The transition was very smooth - none of Ruby developers we had decided to leave because of Elixir. What is more, we kept recruiting Ruby developers w/o any requirement regarding Elixir proficiency & we still were able to educate them internally in almost no time. Obviously Elixir comes with some more tools in the stack: Credo , Hex , AppSignal (required to properly monitor BEAM apps).

First major improvement to the stack was related to introducing React & Redux.js to improve the UX of our front-end applications. Our most popular (by far) dashboard is a complex calendar - a lot of things are happening there & relying on full page refresh was heavily impacting its usability. We've decided to go all the way JavaScript and build a full-fledged SPA.