Conceptually, Assignment 2 is straightforward:
1.vas a team, carry out a ‘development’ task using best practice version control, merging different developer’s contributions using a formal static code review process for each merge.
2. Reflect on the process you have just carried out.
In practice, there are a lot of processes to be carried out which require close cooperation, effective communication and coordination, and considerable attention to detail.
Distributed teamwork is difficult and inconvenient, and the essence of teamwork is commitment and compromise. You must make yourself available to participate in team meetings once a week at a time that is generally acceptable to a majority of team members, even if it is somewhat inconvenient to yourself. Negotiation is acceptable. Rigid insistence on personal preference is not. Make it happen. Use weekends if necessary. If you can’t make it to a generally favoured time be prepared to explain your objections with substantive reasons.
It is critical for this part of the assignment that iteration tasks and objective completion criteria are set at the planning and evaluation meeting that marks the end of each iteration. It is also critical that evidence to support any claim of work-item completion is placed under version control. If work items and completion criteria are not recorded, or evidence to support claims of work item completion is not placed under version control, then those work items will be considered not have been undertaken or completed.
It is your responsibility to undertake an equitable amount of work, make sure your assigned tasks are recorded in the iteration planning documents, and to record objective outcomes for your assigned tasks. It is also your responsibility to provide explicit, concrete evidence of work item completion in the form of commits to version control. No verbal assurances should be accepted.
Work also needs to be completed in a timely manner to prevent hold-ups and bottle necks during development. It is your responsibility to complete your tasks by the target dates, and to communicate and collaborate effectively before the target date if you encounter any issues.
To be explicit: it is not sufficientto just do the work, it must be seen to be done. The work must be planned, criteria for its completion set, the work evaluated against those criteria, and all of this must be recorded and evidenced in the iteration evaluation and in version control.
Note: This is a team-based assignment. However, it is not the case that more team members mean less work or that fewer team members mean more work. The coding task in this assignment is relatively trivial. The bulk of the work in the assignment is in coordinating and
conducting the merge reviews. Fewer team members might mean more coding but the coordination and review tasks are greatly simplified. More team members might mean less code work, but the coordination and review tasks are significantly more complicated. In the end, it comes out about even.
Further Note: This assignment uses the principle of ‘evidence -based reporting’. What this means is that is your responsibility to present evidence for the assignment marking criteria to the assessor, and not the assessor’s responsibility to find it. “That wasn’t asked for” is not an acceptable reason for not presenting evidence to support a claim to meeting the marking criteria. Don’t delete your branches, don’t squash your merges, record defects as issues, commit defect rework individually and identified with the relevant defect, keep and present communication logs as necessary, and take and submit screenshots and other artefacts to support your claims to meeting the marking criteria. Make sure the assessor has the appropriate access to check what they need to.
Task 1 – Collaborative Development (90 marks)
This task is intended to develop and assess your understanding and skills in regard to teamwork processes, version control practice, and static testing in the form of formal code reviews.
Assessment for Task 1 has 3 aspects: your performance as a member of a team, your performance in regard your individual and collaborative version control practice, and your performance as author, reviewer, and mediator during the static code reviews.
The actual code development aspect of Task 1 is divided into two iterations. Each iteration consists of a ‘scatter-gather’ cycle using the git ‘feature branch’ workflow as follows:
1. Tasks are assigned to developers during an iteration planning meeting. ‘Completion criteria’ are decided and recorded. Target completion dates are also decided and recorded with regard for any dependencies between tasks.
2. Each developer creates a ‘feature branch’ in which to carry out their development.
3. Each developer completes their development task in their feature branch.
4. Then, on completion of their tasks, and in turn after any previous merge process is complete, each developer issues a merge request, and their work is formally reviewed and incorporated into the master branch.
5. On completion of the ‘merge cycle’, the next iteration’s tasks are allocated, and the cycle is repeated.
Complete the collaborative development task using best practice team processes and behaviour. This involves:
1. Turning up to all meetings
2. Behaving appropriately
3. Taking on an equitable proportion of workload
4. Setting objective completion criteria for all work items. Ensuring work items are
5. Working continuously and consistently, demonstrating that through version control.
6. Communicating promptly on issues, with no surprises on target delivery dates
7. Completing work items to a satisfactory standard on time
8. Providing objective evidence of work item completion or progress in version control
9. Providing evidence of work item completion or progress in iteration reports
10. Providing thorough and objective explanations for non-completion of work items in iteration reports.
Complete your development tasks using individual best practice version control. This involves:
1. Frequent small ‘atomic’ commits – “commit early, commit often”, “commit related changes”
2. Meaningful commit messages
3. Commit working code
4. Don’t commit personal files (i.e. your individual project configuration files)
5. Don’t commit generated files such as binaries
6. Follow agreed team conventions (i.e. development directory structure etc)
Complete merges using best practice merge protocols. This involves:
1. Coordinating the merge cycle with team members before issuing the merge request.
2. Updating your feature branch from master (and deconflicting and debugging it) before issuing the merge request.
3. Submitting the updated, deconflicted and debugged final code for formal review with a merge request.
4. Waiting for the results of the review and then carrying out any rework promptly
5. Addressing each defect with an individual commit identifying the defect in the commit message
6. Ensuring that the master branch executes correctly both before and after the completed merge.
7. Use a new feature branch following the merge for any further work.
In practice, the ‘merge cycle’ is a highly coordinated process which requires close cooperation, timely communication and response, and rapid execution of each stage of the review process.
Since merges must be carried out sequentially, later merges are highly dependent on the prompt and efficient execution of previous merges, and the whole cycle takes a long time to complete. Therefore, it is highly desirable that ‘development’ tasks are completed in the early part of the iteration, leaving plenty of time to conduct an orderly and effective set of merge reviews.
The formal static code review is conducted as part of the merge process. The code to be reviewed consists of all the files assigned to the developer for updating. The files to be reviewed should be stated in the merge request. The objective of the review is to ensure that the submitted code meets all coding standards as provided in the assignment resource section of the subject website. Assessment for the code review aspect of the assignment depends on the final quality of the code you review, not only on the quality of the code you produce.
Complete the code review aspect of each merge using best practice static code review protocols. This involves:
1. Wait your turn before issuing the merge request
2. Update your feature branch, and perform any required deconflicting and debugging before issuing your merge request
3. Respond promptly to any rework requests
4. Address each defect with an individual commit identifying the defect addressed
5. Ensure the master branch executes correctly following your merge
1. Carry out the review task promptly and thoroughly
2. Restrict your review to the files identified for review, and the purpose of the review
3. Identify defects individually and provide an informative comment stating the reason for identifying the defect
4. Respond promptly to any notifications of rework completed
1. Coordinate effectively with the mediator of any previous and following reviews
2. Ensure code meets entry criteria before initiating the review
3. Notify the author when it is their turn to perform their merge (and chase up if necessary)
4. Notify the reviewer when it is time to perform the review (and chase up if necessary)
5. Notify the author when the review is complete and it is time to perform rework or complete the merge
6. Verify that the master branch still operates correctly following completion of the merge.
The critical quality criteria for the merge and code review aspects of collaborative development is that the master branch should remain bug free and operational at all times – both before and after any merges. This is expressed most succinctly in the maxim:
“don’t break master”
Do not underestimate the difficulty and time required to review and integrate three or more separate developer’s code contributions. The submit/review/rework/approve cycle can take several days, so the entire integration process can potentially take well over a week. Aim to complete individual development well before the end of each iteration in order to leave sufficient time to complete the review process properly. Remember, the focus in this assignment is on teamwork, correct use of version control, and correct execution of the static code review process – not on the actual code development, which is quite trivial.