CI/CD powered by GitHub Actions
Continuos Integration(CI) | Continuos Deployment(CD) |
---|---|
- Description
- Technical Information
- Project management
- Continuos Delivery
- How to use
- Development Operations
- Support
- License
This is a web application for science teachers. The web app can evaluate unit conversion problems validating the solutions submitted by students.
Teachers assign students unit-conversion problems on paper worksheets. After students turn in their completed worksheet, the teachers will use this web app to enter the questions and student responses into a computer to be graded.
Students will convert the following units:
- Temperatures: Kelvin, Celsius, Fahrenheit, and Rankine
- Volumes: Liters, Tablespoons, Cubic-inches, Cups, Cubic-feet, and Gallons
Note: The app does not allow conversion between invalid units.
These project is a ReactJS, Github and Firebase workshop. The following technologies and methodologies were used to implement the web application:
- JavaScript Frameworks
- ReactJS and Jest
- Components Libraries
- Material Components for React (MDC React) by Google Material Design team
- Ant Design by Ant Design Group
- React Suite by HYPERS
- Workflow Automation
- Project Management
- Software Development Methodology
- Scrum with Kanban influences
Since this is a small project, I used GitHub Projects to manage the project though normally I would use Jira or Rally. Adopted Github organizational tooling to support the SDLC of this project.
Following a Scrum/Kanban software development methodology, the artifacts were mapped in the following manner:
Scrum/Kanban | Github |
---|---|
Product Backlog | Github Issues |
Sprint Backlog | Github Projects (ToDo column) |
Epics | Github Milestone |
Story | Github Issue |
Product Increment | Github Projects Board |
The stories where grouped in Epics, moved into the project board stages from ToDo
-> In Progress
-> Review in Progress
-> Reviewer Approved
-> Done
.
Using Templates to created User Stories(Github Issues) and Pull Requests so there is an standard structure for each artifact following the best practices and capturing critical information.
For the development process I used the following branch-based workflow:
-
Branch from master on each new code change request
-
Prefix branch names with
{type of work}/us{issue number}/{description}
Ex.
feat/us21/sass-migration
-
To merge new code additions:
- One Pull Request is created.
- Each PR is linked to a given Issue.
- The PR is validated by running the CI checks.
- Once passed the checks and coverage threshold, the PR can be merged into the master branch.
-
On code commits into the master branch a CD process is triggered, unit tests are ran and on success, the app is build and deployed to Firebase hosting
-
Once the PR is merged the linked issue is closed automatically and moved to the Done stage
This project use Continuous Integration as software development practice to automate the code testing process and it use Continuous Delivery to automate the software release process.
To support the CI/CD practices, two automation workloads were created:
- For CI the Pull Request Unit Test Check workload was created.
- For CD the Firebase Hosting Deployment workload was created.
The web application is publicly accessible on the next url : https://unit-conversion-grader.web.app
To run the web app locally, from the project directory, you can execute the next commands:
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
Launches the test runner in the interactive watch mode.
See the section about running tests for more information.
Builds the app for production to the build
folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
Deploys the latest build to Firebase hosting.
Create an Issue for any bug or feature request.
Expect a response within 2 business days after submitted your bug report or feature request. However, in many cases you'll see a response within 24 hours.
- GNU General Public License version 3
- Copyright 2025 © Raul Proenza