# 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