2. Legal Disclaimer
•
SPARTEZ and Slawomir Ginter are Contractors
working for Atlassian
•
The views and opinions expressed in this
presentation are those of the author and not
necessarily reflect the views of Atlassian
•
All trademarks and registered trademarks are the
property of their respective owners
3. Who this is about?
• Atlassian JIRA Team
•
64 developers (listed in Release Notes)
4. Who this is about?
• Atlassian JIRA Team
•
•
64 developers
3 major geographies (a few “minor”)
5. Who this is about?
• Atlassian JIRA Team
•
•
•
•
•
64 developers
3 major geographies
8 hours between each
Assigned to Themes in given Release
Experts for old or brand new areas
6. Who this is about?
• Atlassian JIRA Application
•
•
12 years old
Core and 150+ components
... and some add-ons
•
•
Behind the Firewall & Hosted
Different teams, different rules
7. Who this is about?
• Atlassian JIRA Release Cycle
•
•
•
•
Major BTF Feature Releases
Minor BTF Bug fix Releases
Continuous (+/-) Hosted deployments
2 week Iterations
8. Challenges
• When the team grows ...
... beyond collocated / same timezone
... beyond isolated modules
... decentralizing Project an Product
Management
• You wake up with a full dependency graph
9. Stepping on each
other’s toes
• Busy repository
•
“You broke the build!”
! [rejected]
master -> master (non-fast-forward)
•
What’s new?
git log master..origin/master
•
What differs?
git log master...origin/master
•
Should we rebase?
10. Stepping on each
other’s toes
• Busy repository, with branches
•
merging changes in git is easy
... unless you don’t want them on your branch
• Merge responsibility for branches
•
•
•
•
“Where have my changes gone?!”
“Are you done yet?”
“Go merge your changes”
“Go merge my changes”
11. Stepping on each
other’s toes
• Busy repository, with stable branches
•
Cherry picking = merge conflicts
git merge -s ours
git log master..origin/master
•
Feature branches
git show-branch --merge-base
•
•
Local staging repository
With (automatic) CI Plan Branches
12. Stepping on each
other’s toes
• Conflicting changes to the same code
•
•
“Lock” the code if you can
Long living development branch
-
•
git gives hope of clean merge
Who is the “owner” of the code?
-
asking permission vs forgiveness
13. When does code have
an “owner”?
• Collective Code Ownership principle?!
• Cross-product component with dedicated
team
• Actively developed at the moment
• Alien technology, impractical deployment,
special testing needed
• Code Ownership vs Product Ownership
14. Consulting vs Approval
• Peer Review (Post-commit)
•
•
•
•
to validate the (emergent) design
to seek advice
to keep interested parties up to date
new libraries, programming techniques
• Approval for merging feature branch
• Internal Pull Request
15. When Code Review?
• In the same repository
•
•
Branch or single changeset
Safe to leave changes in the repository
• Change is mature and ready for merge (?)
• Expecting approval
• Clear who is going to merge and when
16. When Pull Request
• Non-urgent, high risk or impact change
• Incomplete change
•
•
•
Spike result
“80% done”
Solution proposal
• Expecting reject or indefinite postponing
