4.3 KiB
The BTS Development Process
Projects
Our development work is organized in projects. A project is a non-trivial effort to specify, 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, all tough on occasion development or operational requirements can also suggest valuable project 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, validation and merge.
-
Inception. In this phase the infrastructure for the project is created. 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 BTS's ability to quickly deliver value to customers than good specification work. A specification typically takes the form of a shared google docs using a mix of text and UI mock-ups to capture both user requirements and suggested implementation strategies. Taha and Kevin are 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 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 questions and specification trade off concerns.
-
Verification. Once code is complete it is the project's team job to think carefully about the best way to verify that the work is solid enough to go to production. We do not have a dedicated QA cycle to flush out bugs so it is important for changes to be fully tested before being marked ready to merge (RTM). For any non-trivial change project teams should enlist a 'test buddy' from outside the team to help review the code and think of test cases that they may not have considered. Stability from release to release is especially critical right now as we develop a reputation in the futures world. Additionally, project teams are encouraged to make liberal use of other testing techniques such as
- 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 RTM (Ready To Merge) acronym. 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.