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?