When users make changes to your GitHub repository, they will request that you pull their changes back into your main repository. You should have a consistent QA process to complete this step.
One great way to build a QA process is to learn from the Agile development methodology. Agile is a way to think about building software with continuous deployment cycles. Agile has many ideas associated with it that may help you evolve your nonprofit’s technological capabilities, but the one we’re most interested here is their thoughts around QA.
“The be effective in testing on an Agile project, the QA needs to keep track of the past, present, and the future!” - http://www.slideshare.net/abagmar/agile-qa-process
To understand how to create a QA process, the first thing to understand is what your team might consider an iteration of the product. A usual iteration involves looking at the overall code base each time you make a conscious effort to upgrade the product or a specific capability, but in the open source environment, you may not be able to review ALL the code as there can be instances where you’ll be getting dozens of changes from different volunteers coming in at sporadically. The idea then is that create a buffer between changes that come in from volunteers, and your ultimate production-level code. Most organizations do this by creating a staging environment where they can integrate and test changes before pushing to production. The staging environment is where your (1) community manager should do their basic QA. The (2) first engineer review can happen on staging as well and once this is completed, you should request to push the changes to your production environment. (3) The last step is the final integration and release on the production environment and testing to make sure the product works as expected.
Step I: Community Manager basic QA
Step II: First Engineer code review
Push to Production: Auto tests from Jenkins
Step III: Final Code Review by Production Engineer, Integration, and Release Testing
And Finally: Feedback for Developer by Community Manager
Most of the time, it’s smart to have a staging account on GitHub separate from your production account so that you don’t risk your real product getting broken by changes that might be coming in from volunteers. This helps you create a buffer between what’s live and also allows you to test specific variables without affecting your live product.
Production is the final place the code rests before it’s released. In some circumstances, your production code might in continuous deployment, meaning changes to your production code get pushed live immediately. In these cases, it’s always important to have a staging account before change move to production.
In some cases, it can be beneficial to have your deployments automated and happen every time there is a change to the code. Often, teams that are working on straightforward landing pages like to do this so that content that needs to change daily can be pushed live without much hassle. Heroku has an immediate deployment option with GitHub, which you can learn more about in the index of this playbook.