One of the goals of creating the Pride app was to develop it as an open source project. Right from the start, we decided to make the repository for the source code public on Github. By making the development public we hoped to encourage the tech community to get involved and build a long-term pool of technical volunteers that can sustain the app into the future. We are still on the path to realise this goal. Along the way we have faced some interesting challenges and we have learnt a lot.
As a consultancy, we have a breadth of experience working on a variety of projects. Each of them with their own onboarding process. One practice that we find works well is to make onboarding as autonomous as possible. On Pride, the first point of call when someone new joins is an extensive readme that documents getting set up. Given the project changes over time, onboarding someone new also serves as a good test to ensure we have documented all of the steps to getting up and running. We encourage new starters to make their first pull request and amend any missing pieces.
There are a few areas of our onboarding process that are not autonomous. In particular, sharing secrets and giving access to various 3rd party systems we use. In the future these could be automated, but we have deferred that for now to focus on getting the app functional for Parade Day.
Champions that own parts of the project are a key piece to making the Pride app a success. Champions align the direction and ensured knowledge is shared around a given domain. Champions also help connect the dots when a piece of work has changed owners due to time constraints and other commitments.
At Red Badger, we value working in a cross functional way. This allows different disciplines to work together on problems, get faster feedback and therefore work with greater efficiency. Collaboration has been somewhat difficult on Pride due to the distributed nature of the volunteers, both in time and space. Contributions come in ebbs and flows. It is unrealistic to expect volunteers to devote all their spare time to this project.
Drawing from our experience working co-located with each other, we organised times to collaborate. Most Saturdays for the past three months have had a number of volunteers meet in our office or make themselves available online to work together at the same time. This meant that we could collaborate more closely, tightening feedback loops and increasing our throughput. Questions would be resolved in minutes and features would be ticked of the list.
Channels of communication
In order for the project to be a success communications had to be clear and consumable by others in their own time. To allow for this, the project settled on three communication channels, Trello, Slack and Github. We use Trello to document what needs to be done and progress being made. We use Slack for team communications, notifications, questions and advice. We use Github to track development, seek code reviews, get technical advice and log bugs. All together these channels help us do the right thing and do the thing right.
Another core principle we have at Red Badger is striving for continuous integration and continuous delivery. Across our various internal projects we see huge gains in team velocity by automating build and release pipelines. Pride is no exception. With the future in mind, and the goal to make something that will live on after the festival we automated the build and release process of the Pride app.
Currently we have a number of pipelines that kick off during different stages of development. The first is the branch build. This happens when a collaborator creates a branch with changes to the application. This pipeline will create and test builds for both platforms and make them available for all team members to install. The second is the master build. This happens when a collaborator merges an approved pull request into the master branch. This pipeline will create and test builds for both platforms and make them available for all team members to install and test. The last is the release build. This also happens when an approved pull request is merged to master. The difference here is that the build contains all the settings for production and comes out the other side as artefacts ready to be released into the wild.
Shhhh, it's a secret
Automation has enabled us to keep secrets. No sensitive information is stored in the public repository for the public to see. Instead we keep it out of sight in the build system. Few contributors need to know about this and therefore access can be secured to a few champions.
We still have some manual steps with respect to our releasing. We are learning. As we perform more releases this will be iterated on. Every release is getting us closer to a sustainable way to build and release that will help keep the project alive in the future.
Completing the feedback loop
Once the Pride app is released we gather information around crashes in case changes do not work as expected in the wild. Whenever there is a exception thrown in our application, an issue is automatically raised in Github for a collaborator to investigate. This has been extremely useful and has helped us identify a major problem with maps on a number of Android devices. After several hours of digging, testing on multiple emulators we found a fix. Thanks to our automation pipeline, once the fix was merged, we were able to release to the wild in a matter of hours.
What we have accomplished so far is amazing. I am very proud of the work the team has done. Any contributor can onboard, make changes, and install the updated app on their device and use it within a few hours. That being said, we still have work to do. In particular, learning how to automate the release process in a sustainable way and improving the contributor experience so they can keep the development alive.