How we work

To avoid mistakes, and to accurately track things, we try to maintain a certain process when developing SecondFunnel.

Product Planning Workflow

Building the product is more than just writing code. Product development is iterative, through a few stages (which should be recognizable if you're familiar with different agile practices):

1. Backlog prioritization
2. Sprint planning
3. Daily scrum (stand up)
4. End of sprint retrospective

Most of this is managed for us, but there are a few important things to note.

Backlog

The backlog is a prioritized listing of all the features / bugs / etc. that we would like to accomplish. At the moment, it is prioritized by the Lead Developer, but anyone is welcome to add new issues to it. When doing so, please add the issue to the appropriate project, if possible, and put it at the end of the backlog.

Sprints

A sprint is length of time, typically 2 weeks, where software is developed and certain deliverables are committed to. The idea is that at the end of a sprint, you should have an incremental piece of functionality that you can choose to ship. Over time, we can can estimate how much work will fit into a sprint. Sprints contain stories, which should be small enough that they take no longer than a day to complete, and provide value to a user. Stories can have tasks within them as well.

Daily scrum (Stand up)

The daily scrum is an event where everyone talks about three things:

• What did you do yesterday?
• What are you doing today?
• What are you blocked on, if anything.

It should be a quick meeting, and additional discussion should be held separately. The Lead Developer is responsible for assisting in unblocking people (outside of the stand up).

Development Workflow

Development should be a simple and straightforward process. In our case, here is what happens:

1. A developer assigns an unassigned bug / feature / etc. to themselves from the issue tracker.

2. The developer creates a new branch off of the development branch to do their work in, and starts the task in the issue tracker:

    git checkout -b {branch_name} origin/dev
   

3. The developer makes whatever changes necessary in their local branch. At the end of the day, the developer updates the status of the issue with any new details (e.g. obstacles encountered, new work that need be done) and pushes their branch to the github repo:

    git fetch  # get any updates if there are any
    # git merge origin dev  # keep your branch up to date! 
    git push origin {branch_name}
   

4. When the developer has completed their changes (including any necessary tests), they make a pull request to merge their {branch_name} into the dev branch.

5. Their code is reviewed, and after any necessary changes are made as a result of the review, their code is merged into the dev branch.

6. When we are ready to release, the dev branch is tested. When all necessary bugs are fixed, the dev branch is merged into master and is deployed live.

Issue Tracking

Stories should move from through the following states:

1. Pending: The story has not been started yet.
2. Running / In Progress: The story is being worked on.
   • Blocked: There is some impediment to working on the story.
3. Completed: The developer has completed their work on the story.
   • Accepted: The lead developer has accepted the work on the story, and it has been merged into dev.
   • Rejected: The lead developer has rejected the work on the story. Return to step 2.
4. Released: The story is now live!

Branch Details

There are two permanent branches (dev and master), and one type of transient branch (hotfix branches) in our development process. All other branches should branch off of dev

master branch

The master branch should directly mirror the code that has been deployed to our live server. No changes should be made directly on this branch.

hotfix branches

In the event that a deployment has gone sour in some way, or a critical bug has been released and needs to be fixed immediately, a hotfix branch can be created. hotfix branches should start with hotfix/, and should be branched off of master. When work is completed on a hotfix branch, it is reviewed as normal, but the fix needs to be merged into both master and dev.

dev branch

This is where the majority of work takes place. No work should be done directly on dev, but instead should be done in feature branches off of dev.