Difference between revisions of "Development workflow - webdev"

From WormBaseWiki
Jump to navigationJump to search
Line 53: Line 53:
 
=== Hotfixes ===
 
=== 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 <code>production</code> and <code>dev</code>
 
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into <code>production</code> and <code>dev</code>
 +
 +
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:
  
 
== Commits to dev ==
 
== Commits to dev ==

Revision as of 20:35, 6 March 2013

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.

Diagram

Git Workflow - WormBase1.png

Editable version of the diagram

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, dev 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.
  • dev: any features/changes ready for testing should be pushed to the dev branch. This code gets pushed nightly to staging.wormbase.org.
  • production: the code currently in production. Branched off of master at 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 dev or the fix is completed.

Feature branches

Any new major features should branch off dev. Once the feature is ready for testing, it can be merged back into dev.

Starting a feature branch

git checkout -b myFeature dev

Pushing a feature onto dev

When you're ready to incorporate your feature and have it tested on staging.wormbase.org, you can push your feature branch back to dev

For a smaller feature:

git checkout dev
git merge --squash myFeature
git commit -v

You can use --squash to remove any checkpoint commits you may have added to your branch during development, ie. you may have committed debug statements, or broken changes you have since removed again.

If your feature is larger and would benefit from having the work broken down into several commits, you can rebase instead:

git checkout myFeature 
git rebase --interactive dev

This will open your editor with a list of commits. Each line has the operation to perform (pick or squash), the SHA1 for the commit, and the commit message. By default, each commit has the pick operation:

pick 8af9b68 Update search
pick c180b1b bug fix
pick 36afac4 work on field titles

Changing the operation to squash will squash that commit.

pick 8af9b68 Update search
squash c180b1b bug fix
pick 36afac4 work on field titles

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 dev

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:

Commits to dev

Merging dev to master

Release Management

Example Workflow

New Feature

New Feature (Large)

Hotfix to production

New production release

Links