Git in the Enterprise: How to succeed at DevOps using Git and a monorepo
2 likes1,574 views
The document discusses the integration of Git with DevOps practices, highlighting issues such as Git sprawl, complexity for non-technical contributors, and the importance of communication between development and operations teams. It emphasizes using simplified tools for issue tracking and version control, as well as the benefits of a monorepo for simplifying integration testing. Key practices include maintaining agile project structures, enforcing code reviews, and leveraging continuous integration to assure code quality.
Git in the Enterprise: How to succeed at DevOps using Git and a monorepo
- 1. Git in the Enterprise How to succeed at DevOps using Git and a monorepo
- 2. Job van der Voort VP of Product GitLab Matt Attaway VP of Community Support Perforce
- 3. 3 What We’ll Talk about 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 a Very Popular 10-year Old 3 2005 2015 of developers use Git 69.3% — 2015 Stack Overflow Developer Survey
- 5. 5 DevOps is Growing in 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 about Communication, 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 Use Tools to Communicate, Though • Chat/IRC/Slack • Email • Issue tracker • Wiki • Version control
- 9. As you implement DevOps, the tools you choose and how you use them will matter
- 10. Everyone is a Snowflake • 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 control system is your primary communication tool between Dev and Ops.
- 12. You can use Git without a GMS…
- 13. You can use Git without a GMS… …but no sane person does.
- 14. Why? • Git repos are easy to find and access • Provides a place to communicate about code • Issue tracker • Wiki • One-stop shopping
- 15. 15 Teams and Projects in Git • Be Agile in your Projects • Small teams • Small projects • In Git, create smaller repositories • Split up legacy projects Being Agile
- 16. 16 • Everyone has full 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 Protected branches 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 is also a key place where Ops and Dev communicate
- 19. Issue trackers can become a battlefield
- 20. Use the simplest tool possible.
- 21. Simple tools aren’t magically 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 need a 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 little data as is reasonable
- 24. GMS wikis are good 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 that is 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 projects are great for keeping context of each project tightly confined, bad for integration testing.
- 30. Perfect world: version independence
- 31. In the Real World… • 3 components just went live • They’ve never been tested together; they should be fine • Site is down
- 32. Monorepos give you points in time for integration testing.
- 33. You can do this on your own… … but then you’re building a version control system.
- 34. Famous Monorepos
- 35. You can get code reuse with a GMS, but only a monorepo makes integration testing of components easy.
- 36. Job van der Voort VP of Product GitLab Matt Attaway VP of Community Support Perforce Questions?