Development workflow - webdev
This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management. We use git and GitHub to help us manage development.
Contents
Overview Diagram
Editable version of the diagram
Contributing
Whenever you begin work on a new issue you should create a new branch for it. Any new major features should branch off staging. Once the feature is ready for testing, it can be merged back into staging. These aren't necessarily branches in the main repository - they can be local, or on a developer's fork. Read more on our branching strategy
git checkout -b myFeature staging
Now you can make your changes and commit some code. Read more on commit messages
git add /PATH/TO/UPDATED/FILE git commit -m "Descriptive commit message"
When you're ready, you can push your branch to GitHub
git push origin myFeature
Continue making changes until your code is ready for a code review. Is my code ready for review?
When your code is ready, go to GitHub and create a Pull Request. More info on Pull Requests.
- Go to the repository where you pushed your changes
- Switch to your branch (myFeature)
- Click the green Compare & review button
- After reviewing all the changes, click on Create pull request in the header to send the pull request
- In the description, write a short summary of the issues and changes made along with some links for testing
Wait for another member of the web development team to review and merge your pull request. If more changes are requested, you can push more commits to the same branch and it will be added to the pull request.
Once your pull request is merged, locally bring in the changes and delete your issue branch
git checkout staging git pull git branch -d myFeature
Go to the original github issue:
- Add the Under testing label to your issue
- Comment on the issue to notify all involved that it is ready for testing. Add links for testing for the ease of testers.
- Another member of the WormBase group will close the issue once they have tested it
Is my code ready for review?
- Have written tests demonstrating the problem in the issue
- Fix the problem (ie pass the tests)
- Complete the issue as much as possible without curators seeing an example
- Code style meeting the WormBase standards (indentation, comments, no debug statements)
What info should I include in a Pull Request?
To help your reviewer understand your code, please try to include the following in the Pull Request description
- A link to the issue being addressed
- Short summary of the problem
- Some links to use for testing
- Any other information that may be needed to testing (ie wormbase_local.conf changes, extra files needed, etc)
Commit Messages
git commit -m "COMMIT MESSAGE GOES HERE"
Keep your commit message as descriptive as possible, reference any issues affected, close any this resolves:
This is a summary of my commit. * here is a breakdown of the different changes * mention github users (@tharris) when appropriate * related to #YYY * fix #XXX
Here is a template originally written by Tim Pope at tpope.net:
Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
Testing & Code Review
There are two levels of review in our workflow.
- Code review: At the pull request level, before code goes live on staging.wormbase.org
- At the issue level, before closing an issue
Code Review: Pull Requests
This level of testing is typically a code review before a Pull Request is merged into the staging branch. All members of the core development team are expected to keep an eye on the open Pull Requests and reviewing the ones they are most familiar with. Pull requests waiting for review should be left untouched for longer than two days after being assigned.
- Test out the pull request (check out the branch)
- Take a quick look at the code (are there comments? anything obvious missing)
- Leave a comment on the PR if you notice anything that needs to be fixed
- Merge the PR if you think it looks good
Testing: Issues
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.
If you would like to help test:
- Look at the open issues 'under testing'.
- All the changes for these issues are available for testing on staging.wormbase.org.
- You can test out the changes and leave any feedback you have in the issue comments.
- If you think this feature/fix is ready for production, you can remove the 'under testing' label, or close the issue.
Branch Strategy
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.
Main branches
Inside the WormBase/website repository, there are three main branches: master, staging and production.
master: current, stable code. All new changes brought into master have been tested on staging.wormbase.org and approved by either the curator requesting the change, or the development lead.
staging: any features/changes ready for testing should be pushed to thestagingbranch. This code gets pushed nightly to staging.wormbase.org.
production: the code currently in production. Branched off ofmasterat each release.
Supporting branches
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into staging or the fix is completed.
Feature branches
Any new major features should branch off staging. Once the feature is ready for testing, it can be merged back into staging. These aren't necessarily branches in the main repository - can be local, or on a developer's fork.
Testing issues
All issues need to be tested and closed by at least one person who is not the developer who made the change. Ideally, it would be the curator asking for the feature/fix.
If you would like to help test:
- Look at the open issues 'under testing'.
- All the changes for these issues are available for testing on staging.wormbase.org.
If you are not the developer who pushed the code for this issue:
- You can test out the changes and leave any feedback you have in the issue comments.
- If you think this feature/fix is ready for production, you can remove the 'under testing' label, or close the issue.
Moving a feature to master (pass testing)
First, check to see which issues are currently being tested: open issues 'under testing'
If this list is empty, staging can be merged onto the master.
In github, create a pull request for staging. Look at the Commits and Files changes. In the comment, summary all the features/issues introduced and make sure they are stable. Click on send pull request.
Once the pull request is reviewed, it can be merged into the master branch.
Hotfixes
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into production and staging
Begining a fix
git checkout -b hotfix-issXXX production
Fix the bug and commit the fix in one or more commits. Reference the github issue:
git commit -m "Severe production bug * search redirecting to home page * fix #XXX"
Closing the fix
The fix needs to be merged back to both production and staging
git checkout staging git merge hotfix-issXXX
git checkout production git merge hotfix-issXXX
Development Timeline
See: WormBase Release Workflow
Release Management
When production is ready to updated for release WSXXX:
- Create a new pull request from staging to master.
- Review all changes going into new release. Merge in the pull request.
- Create a new pull request from master to production.
- Review all changes going into new release. Merge in the pull request.
- Tag production branch with appropriate release name.
git checkout production git tag -a WSXXX
