DCDT Development Process

The Direct Certificate Discovery Tool development team uses the Agile Scrum software development method. We have week-long sprints with sprint planning on Tuesdays. Our work is organized in JIRA with the Agile plugin.

Development Process and the Definition of Done

A JIRA issue enters the sprint needing no further elaboration. The goal is to close out the issue before the end of the sprint. The steps below list the process through with an issue is closed:

JIRA issue set to "in progress"
Completion criteria are met
Unit tests have been written
Changeset pushed to personal repository
Local build succeeds
Code review completed
Personal repository merged to main repository
CI passed
JIRA issue set to "resolved"
QA completed
JIRA issue set to "closed"

Code Review

Per the DCDT development team's policy, code reviews must be completed within three core working hours of the time that they are opened. All assigned reviewers must complete the review within that time. Currently, the entire development team is listed on every code review. Code reviews are of the highest priority because failure to complete code reviews blocks team progress. Before a code review can be marked as complete all comments from team members must be addressed.

Commit Message Format

The commit message must contain the JIRA issue identifier that the commit addresses. In DCDT, these are in the format DCDT-#. It must also provide a brief description of the content of the commit. Example:

hg commit -m "fixes issue DCDT-9001. change: added implementation of Foo interface to AbstractBar."

Sprints

Our sprints are a week long and end at COB on Monday. The sprint review and the retrospective occur every Tuesday morning, immediately followed by the sprint planning meeting. In the sprint review the progress made in the previous sprint is tallied. The sprint retrospective is a time to review what went well and what could have gone better in the previous sprint. The discussions from the review and retrospective are useful for the sprint planning that follows immediately. Any issues that were not closed in the previous sprint are pulled into the current sprint and reevaluated during sprint planning.

Personal Repositories

A personal repository is a clone of the code base that is under one user's control. Development is done on a personal repository. This means that when working on a JIRA issue, all changes are committed and pushed to the clone of the main repository and not the main repository itself. Code reviews are created from the personal repository.

Child pages