Process and Development Workflow

Tandem's standard project workflow is heavily based upon Github Flow. A "Day in the Life" of a developer looks something like this:

Daily Standup

At 8AM PST (11AM EST) we do a company-wide standup, which lasts a maximum of 15 minutes. At this meeting, every developer...

  • Gives a quick update on the work they've done since yesterday
  • Reports on any blocking tasks
  • Schedules in-depth conversations needed to unblock or go over newly assigned tasks.

The Project Tracking Board

Tandem utilizes Zenhub to track all internal and client projects. Zenhub sets up a 'Kanban' like board that uses Github issues to track individual cards.

Columns for each Zenhub project may vary slightly, as an example, here are the columns from our internal project named horoscope:

  • NEW ISSUES: Task just showed up on the scence (OTS).
  • ICEBOX: Meta task or future food for thought.
  • BACKLOG: Tasks that have been selected for development, but have not been scheduled.
  • FUTURE SPRINT: Tasks that have been moved into the next sprint.
  • CURRENT SPRINT: Tasks slated for work in current sprint.
  • ACTIVE PROGRESS: Tasks that are currently being worked on.
  • IN REVIEW: Tasks that are candidates for closure.
  • CLOSED: Tasks that are complete.

Most projects should follow a similar setup for their columns/swimlanes

Here are some general guidelines for dealing with tasks:

  • Tasks should all receive story point estimates via the ZenHub Estimate field.
  • Tasks do not currently track against milestones.
  • Tasks can be organized into epics as needed.
  • Tasks move from NEW ISSUES to CLOSED.
  • Tasks can be created by any member of the Tandem organization and at any time.
  • Tasks will be managed and assigned as a team during regularly scheduled standups.

Finding Issues to Work On

Project managers should assign you a healthy backlog of issues to fill your week. You can check the zenhub boards of each repository you are responsible for to find active issues. When you are out of active client issues, you can check our internal project boards for issues to work on.

Working on an Issue

  1. Choose a ticket or issue from the ZenHub board of the project you are working on.
  2. Make sure you start the Harvest Time Tracker for the issue: Harvest time tracker image
  3. Take a look at the issue. If you have any unresolved questions, reach out to your project manager.
  4. Open a new branch from master in the form ISSUENUMBER-BRIEFDESCRIPTION to work on that issue
  5. Add commits to this branch with message form #ISSUENUMBER: COMMIT DESCRIPTION
  6. Push the git push {REMOTE} {ISSUENUMBER-BRIEFDESCRIPTION} when work is complete
  7. Open a pull request

  8. Before opening a PR

    • Run the tests locally: lando composer test
    • Test manually that the functionality described in the task is complete.
    • Run git diff on your code and make sure debug, testing and cruft is removed from the proposed PR code.
  9. Assign the PR to be reviewed by your project manager.

  10. Follow any checklists that are auto-generated by the pull request

  11. Wait for any automated tests (Travis-CI/CircleCI), or manual QA (platform envs, code review) to pass.
  12. Merge the code into master. * This is typically done by a technical project lead.
  13. Delete the issue branch ISSUENUMBER-BRIEFDESCRIPTION. * This is typically done by a technical project lead.

NEVER EVER EVER EVER PUSH ANYTHING DIRECTLY TO THE MASTER BRANCH!!!

Some details may vary on a project to project basis. Every project has a its own documentation typically starting with the README.md and project variances in process will be documented there. For example for projects using Platform.sh as the host in step 2 you would branch from test as test is the canonical branch for Platform.sh based projects, where Pantheon uses master as canonical.

results matching ""

    No results matching ""