The Journey of SLIIT FOSS Website
Initially, SLIIT FOSS website was written in pure HTML, CSS and JS. That project was developed by Nandun Bandara, Shafkhan Mohamed, Ahamed Safnaj and my self. You can find that old repository here, but we have archived it.
Setting up the Project
In early 2020 we wanted to enhance and complete SLIIT FOSS website. At that time we were wondering what frontend technology we should use for this. Since Angular is a TypeScript-based open-source web application framework led by the Angular Team at Google and by a community of individuals and corporations so that Kaveesha Gimhana and I thought to go with Angular, so we created a new project and start working also our entire FOSS team wanted to build this projects as a community and in the end, we’ll have our website, a self driven community and most importantly newbies will learn about how to contribute to an open source project appropriately. So that we divided the project into small parts and raised issues for each.
As a project management tool, we used GitHub Project Board, which help us to track our tasks.
In addition, we intergrated this repository with SLIIT FOSS slack channel because our members are able to see what's happening in the project.
Continuous Integration & Continuous Deployment Pipeline(CI/CD)
Then after we asked our members to pick an issue do the work and send them as Pull Request. Unfortunately, once someone has sent a PR(Pull Request) with errors and without knowing we merged it. So we wanted to have a CI (Continuous Integration) pipeline to prevent that kind of situation because through that we can build and test our project before merging PR into master or main branch.
There are several CI tools out there. However, we choose GitHub Actions. GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. We can build, test, and deploy the code right from GitHub no need to go for 3rd party tools, GitHub Action helps to make code reviews, branch management, and issue triaging work the way we want. You can find more details about GitHub Actions from here.
Actually, we created two GitHub Action workflows for this.
- The first GitHub Action triggered when it gets a PR to the master branch and build the project. So we can get to know whether the project is building without errors, if there any errors.
2. The second GitHub action triggered when master branch gets a new commit. Then GitHub Action will build the project and deploy SLIIT FOSS website to Firebase Hosting. So we don’t need to manually deploy our website. I have a written an article about how to deploy a web app to firebase hosting using a GitHub Action you can read from here.
Code Reviewing
CI/CD pipeline were not sufficient since code reviews were one of our requirments. It provides a fresh set of eyes to identify bugs and simple coding errors before our project gets to the next step and also newbies don't know about coding standards and best practices. Through code reviews, we can give comments about their code in PRs. Since prevent accident merging not reviewed PRs to the master branch we created a branch projection rule in GitHub, We can define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history.
We used another good practice in this project. That was GitHub codeowners, Code owners are automatically requested for review when someone opens a pull request that modifies code that they own or their expertise. Since from the beginning Bawantha Rathnayaka was main styling guy of the project so I defined him as a codeowner for all CSS files. If someone’s PR contains a change of a CSS file or created a new CSS file Bawantha Rathnayaka will be notified and his review is needed to merge that PR.
We included Sajeetharan for code reviewing. Since he’s a Google Developer Expert for Angular and an industry expert in Sri Lanka, his code reviews are very important for us and also, that will be great opportunity for our contributors to get involved with an industry expert.
Our code reviews were conducted as of the figure below. Every contributor must include a screenshot of what he/she has changed, then we will able to easily review it. If there are changes need to be handled, we asked them to do them.
To identify pending PRs’ statuses we used GitHub labels. 🏷
How Project Development Went
Rather than just making a web app for SLIIT FOSS we wanted to give SLIIT FOSS members about the real-world industry project development experience, that’s why we setup many things and best practices. We believed at least they will learn something. Luckily we were right because there were some members who didn’t know Angular, How to create a PR, even what’s GitHub, they went through our guidance and learned those things and made a huge contribution to the project.
We received so many contributions throughout last year Hacktoberfest. We even got contributions from foreign people.
Currently we have 17 contributors and 32 forks.
Production Release to Kubernetes with Platformer Console
We got a free Azure Kubernetes Cluster from Platformer. So we used AKS Cluster and Platformer Console to do the production release because Platformer makes Kubernetes deployment easier, with no truckload of config files. As a container registry, we have used the newly released GitHub Container Registry.
Note: I’m the one who developed Platformer CI/CD in both backend and frontend parts which used to connect SLIIT FOSS repository and Platformer Console and automate the deployment using a generated GitHub Action.
Haha!🤭, I know you might be wondering how production builds actually happen. I’ll add a diagram below.
As of the following figure, you can find our public docker image in GitHub Container Registry.
Finally, I want to thank all contributors who help us to lead this project to success Sajeetharan for giving us a lot of advice and Platformer for giving us free Infrastructures to deploy our web app.
