Skip to content

General_Development_Process

Jump to bottom Edit New page
Matt Wagner edited this page Oct 25, 2012 · 1 revision

{{toc}}

General Development Process

Sprint

Goal

The ultimate goal of each sprint is to deliver a batch of complete features.

Normal Sprint routine

  1. Team member claims a feature in redmine. This means they are the ‘lead’ for this feature. Others may claim tasks that are part of this feature, but should always coordinate with the person who initially claimed the feature to avoid confusion or overlap.

  2. Team member fleshes out any missing tasks for that feature that must be completed prior to that feature being acceptable and sets the task to ‘in progress’. Example tasks that are often omitted during planning:

    1. cuke/rspec tests
    2. documentation
    3. preparation of dependent rpms
    4. additions to puppet configuration
    5. patch review

  3. Team member (s) can work on something on a public branch until complete. It is the feature lead’s responsibility to ensure that the branch is fast-forward apply-able to master.

  4. When the code work is complete do any git fetch/rebasing required to ensure that your patch will apply cleanly to the HEAD of next, then format-patch & send to the group for review. Set Redmine task to ‘feedback’. In the comment, put the last commit hash before the patchset, so if the reviewer has trouble applying it, they know where to fall back to. Patch writer will still need to rebase, but this should speed up the process a bit, so there is less time wasted resending to list.

  5. Reviewer ensures

    1. Code quality
    2. dependencies exist in yum repos on fedora|fedorapeople
    3. acceptable test coverage

  6. Upon ACK, the patch should be merged onto the master branch (should be fast-forward), unless it is being developed on a public topic branch (in which case that is where it is pushed until feature meets ‘done’ criteria). Set Redmine task & the patch review to ‘closed’, add commit hash as a comment. If this is the last task to complete a feature, the feature should be marked ‘closed’ as well.

  7. The last week (for now) of each sprint will be devoted to fixing bugs that have come up during the sprint and/or outstanding bugs from previous releases, packaging preparations, and demo preparation.

What is ‘done’?

A feature is considered done when:
* All described aspects of the feature work as expected
* The app continues to work from end to end with patchset applied. This is especially important for any model changes, as they may have unanticipated side effects on a component that was not intentionally affected.
* It is the responsibility of the feature lead to facilitate the following, even if they are not the one doing all steps:
*** All new dependencies must be packaged as RPMs somewhere, ideally fedora, our yum repo is a good temporary fallback.
*** RPM spec for conductor (and other RPMs we own, as needed) must be updated to reflect new dependencies.
** Any changes to puppet or initscripts must be accounted for.

Wrap Up

Each sprint is a time-boxed release 3 weeks in duration. The following points apply to what happens at the end of the sprint.

  • Wednesday:

    • Last day of the sprint. Any tasks in progress should be sent to the list by end of day. If something is not ready by this time, the task or feature (whichever makes more sense) will not make it into the just-ending sprint.

  • Thursday:

    • Sprint Review/demo. This is the time to show off what has been added and bring up any issues with current sprint features that the team may not be aware of. The goal is to demo an rpm-based installation of all new features delivered in this sprint. This allows the project stakeholders to see the progress that has been made and comment on new features (and potential ask for changes to the feature in an upcoming sprint).
    • Before and after the call, the entire team should be reviewing patches on the list and testing the app end to end. Barring major problems, all patches should be pushed by end of day.
    • Project backlog maintenance (based on seeing the new features in action, project stakeholders may create new feature requests, remove feature requests that no longer seem important, or change the priority order of feature requests before the next sprint starts.

  • Friday/Monday:

    • Sprint planning meeting to determine what we think we can do in the next sprint. Ideally, the backlog has been shuffled to correct order of importance by product owner and stakeholders before this meeting. The team will work with project stakeholders to ensure that the everyone understands what is expected to be delivered for each new feature. There will often be some group discussion to ensure everyone is on the same page with regards to the functionality that must be delivered and areas that will require integration for each new feature to be fully functional. Any features that did not make it in will be reassessed by product owner to determine if they are of the same importance as before, and if they get rolled into the next sprint or deferred.
    • Everything should be packaged/updated in repos. All developers should be testing and having further discussions on feature details as needed. By EOD, there should be a decision whether we have a suitable candidate for release based on the just-ended sprint. Assuming yes, a release should be ready, yum repos updated with final packages, release tagged, email sent to mailing list making release announcement.

Scrums

Scrums are held daily and weekly.

All scrums take place in irc (#aeolus-scrum, we will likely move this to freenode once Redmine is public). They are slightly more flexible than a typical in-person scrum due to the distributed nature of the team, but follow the same basic format:
* What did I do yesterday (or earlier today, if scrum is at your eod)
* What am I doing next?
* Blockers (this could be an external dep, you are just stuck on something, or anything else making your task take longer than you expected, also a handy time to mention any patches that need review but don’t have a reviewer lined up yet)

Please include ticket numbers you are working on and set their status before giving your update in the scrum.

Daily Scrum times

We currently have 2 time slots. All developers should give a daily update in the time window for their team. You can get your local time with date -d '15:00 UTC' (Thanks Slow for helping me get that command right).

Bugzilla States

We tried to simplify the states and were reject by the bugzilla admin

  • NEW (bug opened)
  • ASSIGNED ( the bug has been assigned to a dev)
  • ONDEV
    * POST ( dev has submitted fix to [email protected] and is awaiting ACK)
    * MODIFIED ( dev has committed code)
    * ON    QA ( bug fix is consumable by QE, in a yum repo )

Bugzilla info

When reporting new bugs, please try to include as much relevant information pertaining to the bug as you can in the initial report. Logs and output should be included as attachments to keep the actual comments as concise and scrollable as possible. The following information is useful to include (either partially or in their entirety) in a bug report (if they contain errors and such):

  • aeolus-configure output
  • conductor logs: /var/log/aeolus-conductor/rails.log and /var/log/aeolus-conductor/thin.log
  • deltacloud logs: /var/log/deltacloud*
  • imagefactory logs
  • aeolus-cli output
  • web form parameters
  • aeolus-configure node parameters (if they are able to be shared publically)
  • any additional data relevant to replicating the issue
Add a custom footer
Add a custom sidebar
Clone this wiki locally