Employee Scheduling Web Application with
DevOps Focus

Aug 2024 - Dec 2024

Summary

My group developed an employee scheduling application while documenting our project processes, particularly how we facilitated Scrum during this project, DevOps processes, and CI/CD practices. Our backend was developed in Flask, and our frontend was developed in Next.JS. We utilised a Model-View-Controller architecture for our application.

My Specific Contributions:

Scrum master for this project, maintaining collaboration platforms such as Jira and Confluence and facilitating standups, reviews, and retrospectives.
Lead DevOps engineer, implemented entire CI/CD and testing pipeline for automated testing, integration, and deployment of web application. Handled deployment of backend and database.
Backend developer, worked on developing backend application models and controllers in Flask connected to a relational database.

This project was undertaken as part of an SMU module, 'IS212 Software Project Management'. I received a distinction for my part in this project and for this module overall.

Project Details

This web application is intended as an employee scheduling portal, where different classes of users (Staff, Managers, Directors, HR, and Senior Managers) have different capabilities within the application.

Users can make work from home (WFH) or in-office arrangements for days of the week, while manager-level users can manage the requests of those under them, and senior managers and HR can view the requests of all users.

While this web application was the final deliverable of this project, the most interesting part of this experience was our deep dive into optimal software project management processes, particularly Scrum methodologies and Continuous Integration / Continuous Deployment (CI/CD) techniques.

Application Users

There are three possible types of users that may use our application, and for each user the application will offer different capabilities.

Staff
Managers & Directors
Human Resources (HR) and Senior Management

Staff

Staff are able to:

View their own schedule.
View their team members' schedules.
Apply for a working arrangement on a certain day.
Change/Withdraw a selected working arrangement.

Personal schedule view.

Team schedule view.

Request arrangement.

Withdraw arrangement.

Managers & Directors

Managers & Directors are given additional capabilities to manage teams under them:

Approve and reject arrangements from team members.
View approved and rejected arrangements from team members.

Approve and reject arrangements view.

View past approved arrangements.

Humans Resources (HR) & Senior Management

HR & Senior Managers are given additional capabilities to manage departments and teams:

View all departments in organisation.
View all teams in each department.
View schedule of any chosen team.

All departments view.

All teams under chosen department view.

Schedule of a single team in chosen department.

Continuous Integration

I developed a suite of test functions for our RESTful APIs developed in Flask. To do this, I utilised the PyTest library due to its ease of use and flexibility. Our backend development team utilised the paradigm of Test-Driven Development (TDD), where for each RESTful API function we would first write the code for all of its test cases, and then write and refactor the actual function's code until it worked well.

The next step was to make this testing automated on every push to our repo. To do this, I configured a GitHub Actions yaml workflow to run our suite of PyTest functions on every Git push to either our backend or main branch, to constantly validate that code developed and pushed by our backend team was correct and working as intended. On any test failure, notifactions would be sent to team members.

Our group enforced a minimum 80% test coverage throughout our development process to ensure we had a clean and correct code base, and ended development at a 97% test coverage.

Continuous Deployment

Continous Deployment for our frontend was handled by the platform we deployed our frontend on, Vercel. Thus, my priority was continuous deployment for our backend to our PythonAnywhere server.

For this, I configured an encoded GitHub Actions webhook to an API aimed at my PythonAnywhere deployment server. Upon receiving this webhook, a script I wrote in PythonAnywhere would run a bash console command to git pull and git merge to the server's codebase.

While this required webhook signature validation using webhook tokens and HMAC encoding, this allowed for seamless deployment of our Flask backends on every push to our main or backend branches, usage logs, deployment logs, error logs, and scheduled running of scripts on the server.

Scrum Master

As Scrum master I was in charge of organising the team and facilitating Scrum meetings including:

Daily standups.
Sprint reviews.
Sprint retrospectives.

I helped to organise the team and direct development efforts throughout our 5 months of project development. We collaborated on Jira, using the integrated Backlog Boards to plan user stories, acceptance criteria, and assign story points to our user stories using Planning Poker on a fibonacci sequence.

User stories were managed on backlog boards, and during each 2 week sprint we tracked progress on Jira's Kanban Boards to ensure our frontend, backend, and testing developer teams were aligned.

Confluence was integrated to our Jira workflow, and it was used as a shared repository of information. Key documents we had included:

Customer briefs.
Database schemas.
C4 diagrams for our application architecture.
Definition of done for both frontend and backend.
Story point estimation process document.
Test cases.
Minutes for all meetings.

Burndown charts from Jira were useful in helping our team document our velocity throughout our sprints, understanding our pace of work and our capability to deliver product features each sprint.

And...

I made the logo too! AIO stands for our app name: All in One.

Logo.

Employee Scheduling Web Application withDevOps Focus