Join GitLab VP of Product Job van der Voort and Perforce VP of Community Matt Attaway to hear lessons learned from their customers on how to succeed with DevOps using Git and a monorepo. In this webinar we'll discuss: - Approaches for managing teams and projects using Git - Techniques for handling issue tracking across dependent projects - Methods for automating testing and deployment - Strategies for bringing enterprise scale, cross-project visibility and security to teams using Git

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?