Skip to content

General_Development_Process

Jump to bottom Edit New page
Mo Morsi edited this page Jan 9, 2013 · 4 revisions

General Development Process

Sprint

Goal

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

Normal Sprint routine

  • 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.
  • 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:
    • cuke/rspec tests
    • documentation
    • preparation of dependent rpms
    • additions to puppet configuration
    • patch review
  • Team member 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.
  • 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.
  • Reviewer ensures
    • Code quality
    • dependencies exist in yum repos on fedora|fedorapeople
    • acceptable test coverage
  • Upon ACK, the patch should be merged onto the master branch , unless it is being developed on a public topic branch . 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.
  • The last week 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 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 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 .
    • 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 . 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
  • What am I doing next?

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' .

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)
  • ON_DEV (optional, bug has been picked up by assigned dev)
  • POST ( dev has submitted fix to aeolus-devel@lists.fedorahosted.org 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