Download to read offline
Git in the Enterprise: How to succeed at DevOps using Git and a monorepo
- 1. Git in theEnterprise How to succeed at DevOps using Git and a monorepo
- 2. Job van derVoort VP of Product GitLab Matt Attaway VP of Community Support Perforce
- 3. 3 What We’ll Talkabout Today • When Git meets DevOps • Managing Git teams/projects • Issue tracking & wikis • Integrating CI into dev • Integration testing • Advantages of the monorepo 3
- 4. 4 Git is aVery Popular 10-year Old 3 2005 2015 of developers use Git 69.3% — 2015 Stack Overflow Developer Survey
- 5. 5 DevOps is Growingin the Enterprise 5 69.3% 2005 2015 63% — State of DevOps Report Puppet Labs of developers use Git of Enterprises are practicing DevOps — 2015 Stack Overflow Developer Survey
- 6. 6 When Git &DevOps Collide • Maximum practical repository size • Git sprawl • Too complex a tool for non-technical contributors • Raises security concerns • Little visibility across the product development pipeline • Creates challenges for DevOps team practicing continuous delivery Git Can Pose Issues for the Enterprise
- 7. DevOps is aboutCommunication, Not Tools • You can’t buy a DevOps tool • You can’t hire a DevOps engineer • DevOps is about bringing your dev and ops teams together, not inventing a new team
- 8. You Do UseTools to Communicate, Though • Chat/IRC/Slack • Email • Issue tracker • Wiki • Version control
- 9. As you implementDevOps, the tools you choose and how you use them will matter
- 10. Everyone is aSnowflake • Each company and team is different • Those differences are usually for good reasons • Think about how you are using your tools to communicate: - What’s hard? - What is more complex than it needs to be?
- 11. Your version controlsystem is your primary communication tool between Dev and Ops.
- 12. You can useGit without a GMS…
- 13. You can useGit without a GMS… …but no sane person does.
- 14. Why? • Git reposare easy to find and access • Provides a place to communicate about code • Issue tracker • Wiki • One-stop shopping
- 15. 15 Teams and Projectsin Git • Be Agile in your Projects • Small teams • Small projects • In Git, create smaller repositories • Split up legacy projects Being Agile
- 16. 16 • Everyone hasfull access to the repository • Everyone can push new branches • Keep your Git flow simple • Avoid over-management of branches • Getting started should always be easy Working with Git the way it’s intended Teams and Projects in Git
- 17. 17 • Use Protectedbranches to enforce code review • and to protect your master, production branches • Use Approvals to ensure owners of the code see and review the changes before merging • Always do code review • Many small merges are better than few large merges Using the right tools Teams and Projects in Git
- 18. Issue tracking isalso a key place where Ops and Dev communicate
- 19. Issue trackers canbecome a battlefield
- 20. Use the simplesttool possible.
- 21. Simple tools aren’tmagically better, but they keep process focused on communication • Clean conversations/commenting system • Basic voting • Minimal, project specific custom fields • Your GMS probably has everything you need
- 22. You might needa standalone issue tracker if... • You’re in a regulated industry • You have a lot of non-developer contributors • You have a very large backlog
- 23. Collect as littledata as is reasonable
- 24. GMS wikis aregood enough for a technical audience • If you need tables or have users that dislike Markdown, you’ll need a standalone tool • Create projects for teams to handle team wikis • Runbooks are perfect for GMS wikis (and are versioned!)
- 25. Keeping everything thatis related in one place improves communication • Bouncing between tools makes it easy to get lost • Keeping info together helps keep devs in the flow
- 26. 26 Continuous Integration Integrated • You want to be confident in your code, CI allows you to shield anything that doesn’t pass your criteria • You can move faster, no need to wait for complex builds to finish before moving on • See progress in stability, coverage and developer confidence Why CI is important
- 27. 27 Continuous Integration Integrated • Fully Integrated: You always know whether a commit has passed • Based on Git: Your build script (.gitlab-ci.yml) is versioned and therefore will always work, no matter how old the commit • Artefacts, Coverage, Statistics, Deployment • Merge when Build Succeeds: Ultimate timesaver CI in GitLab
- 29. Lots of projectsare great for keeping context of each project tightly confined, bad for integration testing.
- 30. Perfect world: versionindependence
- 31. In the RealWorld… • 3 components just went live • They’ve never been tested together; they should be fine • Site is down
- 32. Monorepos give youpoints in time for integration testing.
- 33. You can dothis on your own… … but then you’re building a version control system.
- 34.
- 35. You can getcode reuse with a GMS, but only a monorepo makes integration testing of components easy.
- 36. Job van derVoort VP of Product GitLab Matt Attaway VP of Community Support Perforce Questions?