Website: rappiddevelopment.com
Here at Rappid Development headquarters, we mainly use GitHub, JIRA and Jenkins to help us to build software. We try to be as collaborative as possible and sometimes, keeping business stakeholders, product owners, developers, and testers all in sync during the software development lifecycle can be a tough task.
We have deeply integrated these tools togther to bring all parts into one streamlined process. Issues in JIRA are automatically updated and transitioned based on a developer's work in Git; JIRA understands all branches, commits, pull requests and build/deployment statuses. Every issue is kept up to speed automatically, and developers, code reviewers, testers and business stakeholders can easily track core code changes, build statuses and prior pull requests. This ensures smooth handoffds between engineers and leads to better results, delievery times and higher quality software.
This document outlines that process and can act as a reference for all team members.
- Developers -
Testers(Coming Soon)- ~~Testing a story~~~
Writing a story defectWriting test cases
Product Owners(Coming Soon)Creating a ticketCreating acceptance critera
C.I Information(Coming Soon)BuildsEnvironmentsDeploying a build
Our Kanban board
Regardless if the project is using Scrum or Kanban, the board is where all work for the project is visualized. Tickets are never really assigned to anyone; the team of developers pick them up as the project advances.
The backlog column is home to tickets ready to be worked, but that have not been started yet. These tickets contain a definition of ready and have the business requirements, acceptance criteria and implementation details outlined and understood.
The failed column is home to tickets that have been implemented, but haven not passed code review, testing or acceptance from a product owner. There shoud be an explaination as to why the ticket failed.
To start developing, select a ticket from either column.
There are three types of tickets that can land in the backlog:
- Story - captures the description of a feature from an end-user perspective.
- Defect - a problem found after the story (functionality) has been accepted.
- Technical Story - focused on non-functional stories, for example: security, performance, or scalability related.
We normally follow a feature branching pattern. There are two main branches:
- Master - current production code
- Develop - code for next production release
Every ticket in the backlog gets it's own branch. Create a branch for the ticket you are working on and follow this convention.
feature/<ticket-number>
For example, let there be JIRA ticket WR-112
$ git checkout -b feature/WR-112
defect/<ticket-number>
For example, let there be JIRA ticket WR-78
$ git checkout -b defect/WR-78
technical/<ticket-number>
For example, let there be JIRA ticket WR-356
$ git checkout -b technical/WR-356
Once your branch is created, push it to the remote server.
This automatically transitions the ticket from the backlog or failed columns to in-progress.
Creating a pull-request for the branch will move the ticket to code review. The pull-request being merged will move the ticket to testing and the pull-request being closed will move the ticket to failed.
JIRA supports smart commits. Smart commits allow you to log time, comment and transition a ticket.
The general rule of thumb at Rappid Development is branch for tickets, commit against subtasks. Commit messages should follow this standard.
<subtask-number> #time 1h 30m
WR-113 #time 1h 30m
<subtask-number> #comment Updating README.md. Changes ready for review. #time 1h 30m
WR-113 #comment Updating README.md. Changes ready for review. #time 1h 30m
<subtask-number> #done #comment Updating README.md. Changes ready for review. #time 1h 30m
WR-113 #done #comment Updating README.md. Changes ready for review. #time 1h 30m