Introduction for the new team members.

  1. We use a scrum based, bi-weekly, agile process.
  2. Every 2nd Wednesday we have a Sprint Kickoff meeting where we select tickets to work on in the next sprint. Tickets are chosen based on priorities, e.g. highest priority first and within a priority defects ahead of enhancements.
  3. Tickets are stored in Lighthouse.
  4. github is our source code repository.
  5. We use git flow branching model. Please read Why aren’t you using git-flow?.
  6. When starting work on a ticket, create a feature branch for it.
  7. We subscribe to the Test Driven Development philosophy. Code is considered complete when it has full test coverage and the tests are passing.
  8. Both unit and integration tests are implemented using rspec.
  9. Once all work on a ticket has been completed:
    – commit the changes to the feature branch using the following git commit message convention: “[#TICKET_NUMBER] Your message.” This allows us to cross-reference Lighthouse with github.
    – Then pull develop branch from github, rebase develop into feature branch and push feature branch to github. Rebase will keep commit history clean and linear.
    – Last but not least initiate a pull request on github. Please refer to Using Pull Requests.
  10. Next comes a code review. Developers with a thorough understanding of the code base can take on the reviewer role. When reviewing a pull request, discuss it with developer if necessary. When code is ready for merge:
    – Rebase develop to feature branch and push the feature branch to github.
    – Merge pull request and delete feature branch on github.
    – Last but not least change the ticket state in Lighthouse to resolved.
  11. We use tddium for Continuous Integration. Develop branch commits on github trigger execution of the entire application test suite. You will receive an email notification from tddium. Any failed tests need to be resolved as a priority ahead of working on the next ticket.
  12. QA Team does additional QA on top of test automation. Ticket state is changed to verified if it passes QA. It is changed to open if issues are discovered. Our goal is to have zero re-opened tickets.
  13. Every 2nd Tuesday we have a Sprint Wrap-up meeting where we go over completed and outstanding sprint tickets.
  14. After a Sprint Wrap-up meeting, a release branch is created. Release name is the same as the Lighthouse milestone number for the current sprint, e.g. 1.0.5.4.
  15. After release branch is created we have a day for the final regression testing. Any issues found during regression testing have a priority and have to be fixed in the release branch.
  16. When a release is ready for production, i.e. all tickets are in verified state and there are no failing tests, the release branch is merged into develop and master. The master branch is deployed on production as described in this article: Deploying Ruby applications in the cloud.
  17. On rare occasions, a hot fix release is required in between regular releases. Hot fix naming convention adds a digit to the regular release name. For example if 1.0.5.4 was the most recent release prior to a hot fix, the hot fix name would be 1.0.5.4.1.
  18. Every business day we hold a brief team meeting – 10 minutes scrum at 10:10am.

software development

, , , ,

December 28, 2012

3 Comments