Upload
perforce
View
643
Download
7
Embed Size (px)
Citation preview
Git in the Enterprise How to succeed at DevOps using Git and a monorepo
Job van der Voort VP of Product
GitLab
Matt Attaway VP of Community
Support
Perforce
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
Git is a Very Popular 10-year Old
3 2005 2015
of developers use Git
69.3%
— 2015 Stack Overflow Developer Survey
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
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
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
You Do Use Tools to Communicate, Though
• Chat/IRC/Slack • Email • Issue tracker • Wiki • Version control
As you implement DevOps, the tools you choose and how you use them will matter
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?
Your version control system is your primary communication tool between Dev and Ops.
You can use Git without a GMS…
You can use Git without a GMS…
…but no sane person does.
Why?
• Git repos are easy to find and access • Provides a place to communicate about code • Issue tracker • Wiki • One-stop shopping
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
• 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
• 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
Issue tracking is also a key place where Ops and Dev communicate
Issue trackers can become a battlefield
Use the simplest tool possible.
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
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
Collect as little data as is reasonable
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!)
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
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
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
Lots of projects are great for keeping context of each project tightly confined, bad for integration testing.
Perfect world: version independence
In the Real World…
• 3 components just went live • They’ve never been tested together;
they should be fine • Site is down
Monorepos give you points in time for integration testing.
You can do this on your own…
… but then you’re building a version control system.
Famous Monorepos
You can get code reuse with a GMS, but only a monorepo makes integration testing of components easy.
Job van der Voort VP of Product
GitLab
Matt Attaway VP of Community
Support
Perforce
Questions?