Internal Development Process¶

Puppet’s full time developers have rules, principles and processes that allow them to work together effectively. This document serves to outline what those are, mainly for clearer communication inside the company, but they’re also public information in case our community wants some insight into how we operate.

If you’re looking for a more prescriptive document that simply answers the question, “What can I do that just works with this process?” then please check out Engineering Process Minimal HOWTO.

Iterations¶

• Our iterations will be 2 week iterations bounded on Mondays or Fridays
• Demos on Fridays every week
• Planning meetings every other Mondays
• Rolling Planning Meetings every other Monday from regular planning meetings
  • Goal is to look forward 1-2 iterations
• Retrospectives on every other Fridays

Weekly Status¶

• Team leads will add a weekly status report to the engineering Google Site for their project.
  • That is here: https://sites.google.com/a/puppetlabs.com/main/teams/research-and-development/weekly-status
  • Please include:
    • What got done this week
    • What’s on the plan for next week
    • Status of milestones finished or currently underway.

Cards and Backlog¶

• Teams are responsible for creating cards/tickets for the roadmap objective their team is working on
• You own a card/task until complete or handed off. No blocked column.
• Cards must have an owner identified, and names added as handed off.
• A card is a physical artifact which should be grounded in an electronic system.
• Please us the cards that we UX created and fill out the information as appropriate: Finished cards require updating electronic ticket with information and version targets
• Please read the following for technical notes on what constitutes “done.”
  • “Done done” according to R&D

Standups¶

• What got finished off yesterday.
• What’s happening today.
• Be there and be prepared. No “I don’t knows.”
• If you can’t make it:
  • You must send an email covering yesterday and today.
  • If you are blocked on something, ask for help. Remember, there is no blocked column.
  • Should we split standups and base them on individual boards

A milestone is a discrete set of functionality ready to be tested for usability:¶

• A milestone is met when:
  • Passes CI
  • Packaged and working
  • Documentation for exactly what is working is included. No more, no less. (This is not public documentation, this is basic Engineering documentation for Nick to turn into public documentation).
  • User Validation: UX & Product
• Teams own their milestones
• Milestones have dates and are public and are signed off by owners (QA, UX, Release)

Testing¶

• All code and changes to code must have tests
• UI changes require Selenium tests
• Teams own
  • Integration and acceptance testing. Code is not complete without this. If you need help, ask Dom.
  • Code may not be merged without this.

Kanban board must have the following¶

• Backlog
• Working (With a posted limit for the amount of work in the column)
• Review(With a posted limit for the amount of work in the column)
• Shipped/Merged
• Milestones for the current project posted somewhere on the board.

Code Merge and Review¶

• No code may be merged into any integration branch that ships in Puppet Core and Puppet Enterprise unless it has been reviewed by a senior developer. And no code may be merged without a review (including that senior developers must have review as well).
  • Currently that includes:
    • Deepak Giridharagopal
    • R.I. Pienaar
    • Josh Lifton
    • Josh Cooper
    • Daniel Pittman
    • Jeff McCune (Solutions/Modules/Facter)
    • Mike (for Release specific issues)
    • Dom (for QA specific issues)
    • Ken Barber (Facter/Modules)
  • Sidebar: This does not mean you shouldn’t have anyone you want review code as you develop it if you need specific knowledge about the code base, or some other specific knowledge. But when that code later goes to be merged into a core product that is going to be released, it must be further reviewed by a senior developer.

Team members¶

• Team members engage fully with their current card or find a replacement. You may not throw it back on the board unless it’s taken by someone else or deprioritized
• New team members work with OSS team until ready to move to another team
• Each team will have one Kanban board
  • The board should clearly indicate who is working on what card

Pairing¶

• Pair where pairing gives the most gains
  • We will pair on difficult design or non-trivial development problems
  • New people pair to learn our code. That includes experienced people learning new parts of the code.

Broken Builds are CRITICAL, and the following process is mandated in case of a broken build¶

• If it is clear who broke the build, that person is responsible for the fix.
• If it is not clear who broke the build, the list of committers since the last known good build are responsible for fixing the broken build.
• A broken build assumes priority.
• Noone may merge/push if a build is broken. YOU ARE RESPONSIBLE FOR CHECKING.
• A build may NOT be broken for more than 4 hours. If you’re working on fixing it, and you hit that limit, back your code out.
• You may NOT leave a broken build. If you follow the 4 hour rule, then you stay late. Otherwise, back your code out.

Release Line of Departure: When do we release?¶

1. If we fix RC introduced bugs, we release an RC at the end of the day
2. A Release happens when:
   • When 7 days have passed since the release of an RC which contains no known new (RC introduced) bugs.
3. The person handling the release is responsible for closing related tickets on Redmine

Iteration Release Process¶

• See: Iteration Release Process

RC/Final Release Process¶

• See: Release_Management