Log in

Sign in with your email address and password:

No account? Sign up here.
Forgot your password? Reset it here.
Didn't receive account confirmation email? Request a new one.

Development Workflow

Development workflow guides help us to follow a methodology for creating and deploying great code while working in teams. The following guide will assume there are three persons in the team: Technical Lead, developer A and developer B and that the remote git repository hosting service is github. While the guide is written with PHP/server side coding in mind, it can be used for any language/framework (note: front-end developers may have slightly different workflows due to different tool-sets being used but in essence are similar). A solid ground knowledge of git version control system (particularly branching, merging, rebasing & pull requests) is required. Rule no 1 to remember is: never commit to master branch.

Developer workflow steps

  1. Tickets/tasks are created and allocated to developers. This is usually done/managed by the Technical Lead using – if desired – a project management tool like Jira or Trello (or good ol’ Excel/Google Docs spreadsheet). A handy technique is to prefix tickets with the project shortcode, eg ‘TW-03’ for the Twoggle project’s 3rd ticket (replace ‘TW’ with your project’s shortcode, if your project is ‘Uptasker’, use ‘UT’, etc)
  2. Developer A starts on ticket TW-03. Developer A should create a new git branch using the ticket number as the branch name. So for TW-03, we create (and check out) branch ‘TW-03’:
  3. All work related to TW-03 is done on this branch only. Sub-branches may be created and merged along the way, but should be deleted as soon as they are merged in.
  4. Once work is complete (and tested!) on this ticket branch, developer A commits and pushes this branch to the remote branch.
  5. Log in to github (or wherever your remote repos is, github/bitbucket, etc), and create a new pull request using {release branch} as the base. For small projects, use master as the release branch, otherwise use a dedicated release branch. A pull request (PR) URL will be generated.
  6. Notify the Tech Lead by sharing the PR URL for review (sharing with fellow team members also a good idea). The Tech Lead (and other developers) can now check out branch TW-03 locally and test the functionality on their own workstations. Comments and feedback are left on the PR and developer A makes changes accordingly.
  7. Once all feedback is addressed, the Technical Lead approves the PR and merges the ticket branch into the release branch.
  8. The release manager (usually the Technical Lead for small projects) take care of deploying the release branch to production (or staging environments if those are being used for QA testing). Once TW-03 branch’s code is on production (and tested!), developer A (or the Technical Lead) marks their ticket as complete and developer A is free to work on further tickets.

Development Workflow

Happy coding 🙂

Submit a Comment