When Fedora Linux 38 debuted in April 2023, the Fedora Project community and I had an extra reason to celebrate. The first item in the community's official release annoucement was one we were extremely proud of: our brand-new Fedora Project websites.
The launch of the new websites was the culmination of many months of good, old-fashioned community contribution from the Fedora Websites and Apps team and other teams such as Fedora Infrastructure, Fedora Marketing, Fedora Design, and many more teams. This effort didn't just involve the development of the refreshed websites; it also involved rearchitecturing the team's technical stack and aligning our workflows with modern industry's best practices.
In this article, I will explain how migrating our workflow to GitLab helped us to not only build refreshed websites for the Fedora Project but also reimagine and streamline our community's process for building, maintaining, testing, and deploying them. The result: new workflows that redefine our team's processes to incentivize contribution and avoid the looming threat of potential contributor burnout – not to mention the elegant websites themselves.
Why we embarked on this effort
About two years ago, four Fedora Project community members (Ramya Parimi, Nasir Hussain, Justin W. Flory, and myself) were working on a project together when we discovered that only a tiny group of volunteer contributors maintained our websites. We immediately faced a dilemma that's common in many free and open source projects: Should that tiny group disband or disappear, we were at risk of not being able to maintain our websites and applications. Also, we didn't want the volunteer contributors to get burnt out under the constant stress of maintaining these projects. We needed more hands on deck, and we needed them quickly.
So our former Fedora Community Architect (the position was then called Fedora Community Action and Impact Coordinator, or FCAIC), Marie Nordin, helped us kickstart a community initiative that inspired us to not only refresh Fedora Project websites and applications but also establish more reliable processes and workflows around them, too.
That second part is incredibly important. We focused on enhancing the visual appeal and user experience of our websites — diligently adhering to the best accessibility practices, implementing a native dark mode that aligns with the user's system theme, and effectively advocating for our offerings to the best of our abilities (among other things). But we needed to solve the problem of maintainability, too. That would involve addressing some underlying issues that, although they looked deceptively simple on the surface, profoundly influenced the long-term sustainability of the team's work. Our goal was to ensure that even when we were not around, contributors who would do this work after us would be able to set things up and maintain them in the long run without issue.
To recruit more contributors, we needed to align the way our team worked with current industry practices. Adopting GitLab helped us do that.
How GitLab helped simplify, unify, and standardize
Historically, the website development team employed a range of tools as part of our workflows. Some we developed internally; others we acquired externally and integrated into our infrastructure. But these tools weren't always compatible with one another, meaning extra effort on our part (establishing a standardized business language for effective communication of work plans, progress obstacles, task updates, etc.). That not only impacted our operational efficiency but also drained our resources (for example, we were dedicating meetings solely to the purpose of ensuring everyone was aligned and understood the processes).
Adopting GitLab helped alleviate that burden, because it's a single, comprehensive platform. Our team got acclimated to capabilities like creating and tagging issues and epics to organize work, building Kanban boards and Gantt charts to map work-in-progress and construct functional timelines, and incorporating merge requests as progress indicators in a comprehensive project overview. We then understood how the cohesive nature of GitLab's approach to most aspects (if not all) of the software development lifecycle significantly enhanced our distributed team's overall efficiency.
But we use GitLab for more than just planning and implementation. We completely rewrote the technology stack using industry-standard static site-generating libraries like NuxtJS. GitLab's ability to create and deploy static sites helps us automate our deployment workflow. Then we coupled the revamped frontend with the NetlifyCMS content management system that relies on GitLab as its core. We also simplified the translation pipeline for localizing and internationalizing our website content. By employing continuous integration tools, we were able to generate dynamic test deployments to evaluate our websites before deploying them to the production environment. That success also prompted us to utilize GitLab for storing meeting logs and documentation, streamlining our project management processes even further.
Here's an example.
In the past, when our websites were based on Frozen Flask, we used various shell scripts to maintain it. These scripts would create an OCI container using Podman, build static files, perform translations, and serve the website. You can still find the deprecated repositories where this was the standard development, testing, and deployment method. Although this process was automated using Ansible in our community infrastructure, it seemed complex for less experienced contributors.
After transitioning to GitLab, we could deploy to our fast-changing staging environments directly from GitLab Pages while the slow-changing production environment remained on the community infrastructure. We also utilized GitLab's CI/CD features to test merge requests with ephemeral deployment environments. Since the automation is integrated into the project itself, any push to the primary branch or merge request triggers a deployment workflow. This consolidation of automation into a single unit has further streamlined our processes.
Better workflow, healthier community
Changes like these were critical to the Fedora Project's overall mission to foster an inviting environment for contributors. Our new GitLab-centric workflow improved the experience for team members who wanted to contribute to documenting and translating content without having to navigate the technical intricacies of using Git. By lowering the entry barrier, we aimed to attract prospective newcomers and promote a more inclusive team dynamic.
As a result, we saw content contributions from other teams. And then, gradually, more folks joined us in our revamp efforts, helping to make this community initiative a success.
The GitLab Open Source Partners are building the future of open source on GitLab. Connect with them on Gitlab.com.
Photo by Hannah Busing on Unsplash.
