85 lines
4.3 KiB
Markdown
85 lines
4.3 KiB
Markdown
# The BTS Development Process #
|
|
|
|
## The Big Picture ##
|
|
|
|
Our development work is organized in projects. A project is an effort
|
|
to specifiy, develop and validate a related set of additions to our
|
|
Spark platform. A project can be assigned to one more developers and a
|
|
developer might concurrently be assigned to multiple
|
|
projects. Projects typically start out with specification work,
|
|
proceed to implementation and finish with validation efforts. At any
|
|
given time there will be multiple projects being worked on
|
|
concurrently. A project is concluded when the features it implements
|
|
are merged into the product and deployed to customers.
|
|
|
|
## The Details ##
|
|
Typically project ideas come from sales interactions, opposition
|
|
research and customer feedback, alltough on occasion development or
|
|
operational requirements will also suggest potentially valuable
|
|
ideas. Whatever the source of a project idea the final decision of
|
|
which projects to pursue is always done by management. Once a project
|
|
idea has been selected for implementation the corresponding project
|
|
will go through several phases: inception, specification, development
|
|
and merge. We detail each of these phases below.
|
|
|
|
* Inception. In this phase we create the infrastructure for the
|
|
project. Typically this means selecting a team, creating a project
|
|
case in Jira (that is a case assigned to the team@bluetradesys.com
|
|
Jira user) and possibly creating a new branch for the project. This
|
|
phase is mostly mechanical and the responsibility of Pedro.
|
|
|
|
* Specification. The specification phase turns a usually vague and
|
|
ill-considered idea project idea into a concrete, implementable
|
|
specification that attempts to maximize the value/cost ratio of the
|
|
project. It is hard to exaggerate the impact of a this phase on the
|
|
rest of the project. *Nothing* has more impact on our ability to
|
|
quickly deliver value to customers than good specification
|
|
work. Specification typically take the form of shared google docs,
|
|
using a mix of text and UI mockups to capture both user requirements
|
|
and suggested implementation strategies. Taha is responsible for this
|
|
phase.
|
|
|
|
* Development. Once a specification is complete, a team of developers
|
|
will use a project specific branch to implement the
|
|
specification. Periodically, typically once a week, progress on the
|
|
project is assessed by Pedro, possibly with the help of others. This
|
|
assessment takes the form of code reviews, demos, or just one-on-one
|
|
conversations. To ensure development does not go off on sub-optimal
|
|
tangents, developers are expected to continuously merge master into
|
|
the project branch as well as encouraged to create Pull Requests (PRs)
|
|
early in the project implementation, so that their work is kept
|
|
visible and integrated with that of the rest of the group. During the
|
|
implementation phase developers should reach out to Pedro for UI
|
|
reviews, architecture and design concerns as well as specification
|
|
trade off concerns.
|
|
|
|
* Verification. Once code is complete think carefully about the best way
|
|
to verify that it is good before it goes to production. We don't have a
|
|
dedicated QA cycle to flush out bugs so it's important that a change be
|
|
fully tested before it's marked "Ready to Merge." For any non-trivial
|
|
change consider enlisting a 'test buddy' to help review the code and
|
|
think of test cases that you may not have considered. Stability from
|
|
release to release is especially critical right now as we develop a
|
|
reputation in the futures world.
|
|
- Code Reviews
|
|
- Unit tests
|
|
- System tests
|
|
- Manual tests
|
|
|
|
* Merge. Once a project is considered complete by developers, a PR
|
|
that includes Pedro should be created (unless, as mentioned above, an
|
|
early PR was already created in the development phase). Whether the PR
|
|
already existed or not, its description should be changed to start
|
|
with the "Ready To Merge" statement. This marks the project as ready
|
|
to be merged into master. Once a week, typically on Mondays, Pedro
|
|
will go through every PR marked as "Ready To Merge", build it, check
|
|
it out and if everything looks good merge it to master. At the end of
|
|
the day the resulting master will be tagged with a new version
|
|
number. This version will be go through some additional testing by
|
|
Brian and will then be deployed by Karl and Pete to customers
|
|
throughout the rest of the week.
|
|
|
|
## Tools ##
|
|
* Pre-Merge checklist
|
|
* Code Review tutorial
|