Working process and git branch strategy

Working process and Git branch strategy

John Lu 2016/9/27

Agenda

● Sharing of prior experience● Current developing flow● Which I think a better flow● Discussion of developing flow● Discussion of strategy of Git branch

Sharing of prior experience

● Just share a common way of developing workflow in this industry.● The scale of a product includes hardware/mechanical/UX/software/QA● The issues could be count in number of hundreds.● Hope we can have a smooth workflow

Sharing of prior experience::Role

Leader

Leader

Engineer/Design

Product Manager

Tester (QA)

Customer

Manager

Sharing of prior experience::Before Starting a Project

● Engineer (Project) Leader will give a guideline for this project○ How workflow (schedule/testing/git/….)○ Naming of git branch (there is a case the branch is created by leader)○ Issue Template on BTS (Bug Tracking System)○ Commit Template (one of reason is that BTS is able to hook commits)○ How many reviewer

Sharing of prior experience::Workflow

Discussion Designing

Prototyping/ Implementing Testing

Investigating (H/S)

Release

Sharing of prior experience::Workflow

1. Discussion: Schedule!Schedule!Schedule!

Leader

PM

Leader

Customer

Sharing of prior experience::Workflow

2. Investigating: Cost evaluation,Purchase,Software Tech Survey

Leader

PM

Sharing of prior experience::Workflow

3. Designing: UX survey/experiment/Case study,Flow design (including gesture and transition),Graphic design,Release SPEC (including revised history)

Leader

PM

Leader

Sharing of prior experience::Workflow

4. Prototyping/Implementing:Distribute task (consider code review the task should not be very big),Needed time negotiation,Register Issues,Create branch,Unit test,Automated testing after push to remote,Daily build

Leader

Sharing of prior experience::Workflow

4. Prototyping/Implementing:Code review (Gerrit):

● Whatever I’ve done on local env on Git. Just merge commits into one and push on remote branch for easy reviewing and pretty history.

● Set needed reviewers.● It’s not like Merge/Pull request.● Some cases that doesn’t need to create a

branch. Just need to review.● Branch is merged by leader

Ref: http://docs.openstack.org/infra/manual/developers.html

Sharing of prior experience::Workflow

5. Testing:The testing application is built by server. QA tester should not test it from Engineer.Pre-alpha testing (allow minor issues/limited major issues),Alpha testing (allow minor issues),Pre-beta testing (limited minor issues),Beta testing,Bugs report,

● QA tester should test base on SPEC.● QA tester should judge UN-SPEC.● QA tester should be like a judge

determines what level of bugs/issues.

Leader

Leader

PM

Sharing of prior experience::Workflow

6. Release:Consider schedule,What solved issues/bugs should be released,Depending what issue will be includedthen determine which version should be plus one.

Product rolling out party!

We use this, major.minor[.maintenance[.build]]

Ref: https://en.wikipedia.org/wiki/Software_versioning

Leader

PMLeader

Current developing flow

Which I think is a better flow

● According we don’t have a role of PM. But we can make a project leader.

● Confused with versions…. We should focus on finishing issues. Let’s version off.

● I still think we need a Spec that we are able to follow. Otherwise, we don’t know what we should focus.

Which I think is a better flow

Use Voltron as an example.

Takashi

Alan

Jonathon YukaTakashi Alan

Jonathon

Alan

Alan

DiscussionDesign/

Investigation Implement Testing Release

Project Spec

Tasks

Build Report

Spec

Fix

Clear and clean dashboard

Discussion of developing flow

Shall we have a person to note the discussion?

Discussion of developing flow

Discussion of strategy of Git branch

Discussion of strategy of Git branch