This article has been written to give you some insights into the technology stack and process which creates the ScheduleLeave application, as well as our day to day development, release and testing processes which we thought some of you might have found interesting!
The team at ScheduleLeave love technology, both in terms of gadgets as well as having a deep rooted interest in web development which is how and why ScheduleLeave originally got started.
Technology Stack
Front-End
The front-end has been written mostly using VueJS. VueJS is a modern front-end framework designed for its speed and scalability for large scale applications. In addition to the core of VueJS, we also made good use of several plugins to deliver a consistent and fresh UI including bootstrap-vue, which provides us with a standard set of components, fully integrated for VueJS applications.
We use some PWA (Progressive Web Applications) functionality for our mobile support as well as a fully responsive design.
Back-End
The back-end has been written mostly using Lumen which is part of the Laravel codebase and is designed to be a lightweight back-end API framework.
Additional integrations:
PDF exports – Used to export your invoices each month
Slack integration – Integrates with Slack to show leave booked within your company for today with customisable options for role/office/department
Stripe integration – Secure monthly payments via Stripe
Servers
All servers are hosted by DigitalOcean in the London UK region, DigitalOcean is one of the leading cloud hosting providers with all the security and ISO accreditations you would come to expect from an enterprise hosted piece of software, you can read all about it on their compliance page.
ScheduleLeave infrastructure has been built from the ground up to be scaleable, performant and adhering to the industry security best practices. You can read more about the security we have in place on our help guide.
Please see the image below for our HLD (High Level Design) for the server architecture.
3rd Party
Within ScheduleLeave we rely on a few 3rd party providers including:
For each item which has been developed it goes through 3 stages of manual testing:
Developer Testing – Testing of the individual item changes
Non-Developer Testing – Testing of the individual item changes including a full list of written test cases to cover all possible scenarios
Non-Developer Testing – Testing of edge cases to validate that no items outside of the direct changes has been impacted by the changes
We carry out these stages of testing to give us the best possible chance of catching anything before releasing the feature or change. In addition to the above manual testing we also perform a series of automated tests as explained below.
Automated
Automated tests have been written and will be added to over time as we make changes, to try and cover the majority of use cases within the application. We have in excess of 400 automated test scenarios to validate the application is functioning as required, these consist of:
API integration tests – These make up the majority of the test cases which we have, and are there to validate all of the logic within the application
Front-end End to End tests – These are to carry out a common set of most performed actions on the application, to validate that the front-end of the application is working as required. For front-end automated test cases we use cypress.io
The benefit of these automated test cases, is that they take no time from a person to run. We run these tests cases on every change which gets made to the application before we start going deeper into the manual test cases as explained above.
Deployment Process
The deployment is fully automated with no downtime required with various safeguards in place. The deployment script has been written in ansible and allows us to carry out fast deployments, whilst ensuring the risk is minimised by performing some manual checks before rolling out the full software release. Once the release has finished, further checks are made and then error logs are cleared down as required to track any new issues which may arise.
