Full transcript
0:04so my name is Brent beer I'm one of the
0:07Sales Engineers at github I've been
0:10forgetting at github for a little while
0:11now before that I was on the training
0:14team so you may have seen my face or
0:16been in one of my webinars or seen me
0:18out publicly speaking at a another
0:21conference or doing another workshop if
0:23so I hope you review those talks as well
0:26as you review your code and review this
0:27one as well as you'll review your code
0:29as well so I've been in San Francisco
0:32for a little while so I didn't have to a
0:35little bit of an echo I didn't have to
0:38travel far to actually get here today
0:39luckily so I wanted to jump right into
0:43this right away to talk about what we're
0:46gonna our look at what we're gonna talk
0:48about and see what our goal is here of
0:51course in the title it says pull request
0:53code review and the github flow and I'm
0:57gonna talk about that but a little more
0:58than just rattling off some definitions
1:01or me telling you you should adhere to
1:03this process or me giving you something
1:06to say go back to your office and
1:07immediately make this work that's not
1:09always the case
1:11and there's some some tips we'll see
1:13throughout this and some approaches
1:14we'll see that hopefully you can take
1:17back to your office and work with once
1:19you get there if you do see some things
1:21up here that are familiar to you
1:23maybe you already know how pull requests
1:24work that's great
1:26hopefully there's additional things I
1:28say or there's some additional notes you
1:30may have to ask me at the end during any
1:33QA time where we can kind of discuss
1:35anything that you'd like and I'd like to
1:38discuss about any of different
1:39approaches or how you can take some of
1:41these back to your company and we can we
1:43can talk about how to kind of grow and
1:45change certain culture you may have
1:47within your company as well so let's
1:51jump right into it so this is
1:56at one version I guess of a traditional
1:59software process people work on a work
2:03on some change they have some sprint
2:04planning they have a ticket to get
2:07assigned to someone they do some
2:09development and they make some changes
2:10they have some kind of continuous
2:12integration work testing great glad to
2:14see that but then code review is this
2:17completely separate thing off to the
2:19side because it can't work with their
2:21current workflow
2:22they don't use pull request maybe
2:24because they're using some other version
2:26control tool and besides github they're
2:28on on SVN and they don't even do
2:30branching that well or I don't know the
2:34most developers that I talked to are
2:35more than I'd like to admit
2:37run into problems like this they don't
2:38get good feedback on their code right
2:40away and they often struggle to improve
2:43their own quality of code so this isn't
2:46this is feels pretty rigid to me and it
2:50doesn't have to work that way and I want
2:52to help show that we can all do better
2:55and we can do better for this and maybe
2:59this just isn't maybe what we we have
3:01appear is a version of what you'd like
3:03to have I certainly think this is a
3:05little bit better you have maybe an
3:08issue a bug it features some kind of
3:09backlog depending on your process again
3:12it gets assigned to a person but after
3:14it gets assigned to a person we see that
3:16first commit come in and once we have
3:19that difference of code we have people
3:22able to start opening a pull request
3:24collaborating on their changes talking
3:26back and forth hey I tried this approach
3:28Lauren do you know of another approach I
3:31can work on oh maybe we should talk to
3:33Tim maybe he's got ideas because he's
3:35done this before
3:36and you have this cycle of continuous
3:38collaboration and then continuous
3:42deployment to go test how that code
3:44actually looks maybe you deploy that up
3:45to a staging server using Heroku and
3:48their deployment pipelines and once that
3:50code gets merged in once it gets
3:52accepted or that issue gets closed out
3:54maybe you then merge it in a master or
3:56whatever your default branch maybe we'll
3:58take a look at default branches with
4:00protected branches here in a little bit
4:02and maybe you also then do another
4:04depending on which process you actually
4:07have kind of have the choice to do that
4:08here and this is actually a
4:10generalization of how github itself
4:12works the the core team at github we we
4:16work on changes we have a branch that we
4:18work on them we get feedback from our
4:20co-workers and we deploy that branch out
4:23to production we see how it is how it
4:26looks we actually monitor Twitter a
4:28little bit we have our own internal
4:29monitoring it turns out a lot of people
4:31using github will let us know on Twitter
4:33if things are bad or slow or down for
4:36them so it's kind of a good barrier for
4:38us to actually look at or at at least
4:39one of them
4:41so with this with this workflow we have
4:46I don't know if anyone's seen guides
4:48github.com
4:51just a few people and see if you
4:54attempted to raise your hands a little
4:57bit more what about you have engineering
4:58comm maybe one that people seem a little
5:01bit more proud to raise our hand about
5:03so let's take a little bit peek at both
5:05of those
5:06I love guides I worked with a lot of the
5:09early people who put together our guides
5:11and the one I like in particular is that
5:14github flow guide we put that in the
5:16hello world guide kind of at the very
5:18top so that people would be see okay
5:21this is a general workflow that I can
5:23start applying to my company and here's
5:25a hello world guide to get me started to
5:28actually work with some of these changes
5:33so of course I'm going to be talking
5:35about this flow get up that github flow
5:38and general workflows a little bit today
5:40but the key here is to keep it
5:43lightweight again I'll get more audience
5:47participation how many people have tried
5:49the git flow all right hands that are
5:53still up how many people liked it a few
5:57people
5:58I personally I got a handout at an
6:01audience are at as an audience member at
6:04a conference for the get flow and when I
6:07first started using it at a company many
6:09many years ago I had no idea where to
6:12start with it is it up is it down do I
6:15turn it on its side and see all these
6:16different branches I don't really
6:18understand how I didn't understand how
6:21it actually used that to be effective
6:23when I was first starting software
6:24development but luckily with the github
6:27flow one thing that we really like is
6:28how lightweight it is so we don't force
6:31anyone workflow with this but this is
6:34our suggested flow with this so sorry
6:40this is what we'll be working towards
6:42when we talk about pull requests and
6:44when we talk about code review we'll
6:46talk about collaboration practices we'll
6:48be working towards this and then as I
6:51mentioned the get up engineering blog
6:52this is one of the post up there that I
6:55particularly love it's a mom had wrote I
6:58don't know it says back at June 2nd
7:01he wrote this blog post talking about
7:03how we actually deploy our code and he
7:05walked through the whole process talking
7:07about it and when he talked about this
7:08he actually sent a pull request back to
7:10our guides page to add in this little
7:13extra step of deployment because we we
7:16work a little bit differently than just
7:18a basic github flow we deploy our code
7:20on our feature branch out to production
7:23so I'm dropping I'm starting to drop a
7:25little bit more and more terms pull
7:27requests branches commits deploys we
7:31won't talk too much about deploys but
7:33let's start at the the key thing of
7:36collaboration and the thing that I think
7:38changes everyone everyone's lives when
7:40they get to github calm when they first
7:42see their first project that oh well
7:45this was a really complicated project
7:46it's developed by Facebook it's using
7:48Java or juicing go I don't understand
7:51any of those languages but I do
7:53understand this documentation piece and
7:55that parts wrong and I'd like to
7:56collaborate on just that piece so right
7:59away one of the first early things we
8:00can do to send a pull request is to find
8:03the common piece within their code
8:05we can edit for me a lot of times that
8:07ends up just being a simple
8:08documentation change I keep telling
8:10myself one of these days I'm going to
8:11send a pull request or well not a pull
8:14request but submit a patch to court get
8:16to fix some of their man pages because
8:19if I look through some of the commands I
8:20get confused myself maybe that would be
8:23my contribution for this month so pull
8:27requests themselves work on some change
8:30propose that change back and have a
8:32conversation about it sometimes people
8:35tell me why would I use github I can
8:39just merge changes locally and I can
8:41just push directly to master she'd do
8:44that
8:44there's no collaboration in that and you
8:48don't want to work in a silo you're not
8:50going to be enriching your own software
8:52development learning if you're working
8:53by yourself without anyone else you're
8:56not getting any feedback from anyone you
8:58can't learn from their experiences if
9:00you haven't talked to them and that
9:01talking and that collaboration piece is
9:03one of the most important pieces I want
9:04all of you to remember by the end of
9:06this talk so if I forget it or if I go
9:09over five minutes without mentioning
9:10collaboration just raise your hand or
9:13yell out the word collaboration to me
9:14and we can Anna I'll just yell about it
9:17again so again I mentioned if you don't
9:21know git or github and I'm sure some of
9:23you do inevitably we're at I get up a
9:25conference but maybe you're not a
9:27software developer Chris mentioned
9:29earlier we have 11 million developers
9:31developers on github and traditionally
9:34they there were studies that said
9:36there's only 20 million in the world but
9:37there's so many people nowadays who are
9:39contributing to projects on github
9:40they're writing in markdown they're
9:42finding a misspelling and some
9:43documentation I would count them as
9:46developers if you're just working on it
9:48as a hobby if you've went to a rails
9:50girls or a rails bridge or girl develop
9:54it or any of those great community
9:56organizations out there helping people
9:58learn to code your developer so what is
10:02a pull request pull request start with a
10:05branch that branch itself is when you
10:09have your main set of code so in this
10:11case we're going to call that master
10:13and you decide you find a bug or find
10:16something you'd like to change you work
10:18on a different branch we'll call that a
10:19feature branch and so when you when you
10:22branch off of master and you try
10:24something new
10:24I often relate that to a sandbox
10:28environment you have the full history of
10:30all the code all the text changes all
10:32the files but I want to work over here
10:35not affect what's on master has often
10:37people relate what's on master to being
10:39deployed in production
10:41I want to mess with that and I want to
10:43try something new out and I want to
10:44practice it so that's where branches
10:47actually come into and so once you have
10:49some changes on that branch from when
10:52you created your branch you can propose
10:54those changes back using a pull request
11:01so you have your branch you've made some
11:04changes and you push that change up to
11:06github then github will actually make it
11:08a lot easier for you now once you have
11:10that branch with some different changes
11:12on it it'll pop open a little green
11:16button for you that says compare and
11:17pull requests and you can just get
11:18started right from there once you've
11:20created those changes one one barrier
11:24people said to my abstract I talked
11:26about some barriers people have to pull
11:27requests so here's one of the first ones
11:28they don't understand how to use them
11:31that seems like a pretty big barrier to
11:32entry there's some tool I'm told to use
11:35and I don't know understand how it works
11:36I'm not gonna use it because I don't
11:38feel safe using it but with getting with
11:40github if you start using these branches
11:42and you send pull requests and you just
11:43talk to your your co-workers your
11:46friends your prospective teammates and
11:49collaborate with them they're in its
11:51collaboration again you can actually get
11:53started on this so instead of live
11:57demoing any of my any of my talk here
12:00today I have a series of videos so if I
12:05if I go over something in this video and
12:07you want me to repeat it again just
12:08raise your hand and yell at me to repeat
12:10that what we're looking at
12:29test test test test check check one one
12:33two there we go hey welcome back so what
12:36we're gonna talk about in this this
12:38short little 30-second to a minute clip
12:40I forget how long this particular one is
12:42and I'm just gonna demonstrate this
12:44quick pull request flow I'm gonna I have
12:46a markdown document here called markdown
12:50practice creatively enough and in this
12:54actual project I just want to add to the
12:57readme add a little bit of markdown that
12:59actually says how to do this and I want
13:01to put this out there just so we can get
13:03everyone to a baseline of what it looks
13:05like to edit some code and send a pull
13:06request and and one thing that often
13:10shocks people when I go through and I
13:13edit this this line of code and I just
13:16add this little bit of markdown is that
13:17I'm actually gonna be sending this pull
13:19request to myself some people often when
13:22they're first exposed to github and pull
13:24requests is they send their pull request
13:26from some other open-source project that
13:29they didn't have access to over to
13:30theirs so I'm just sending this to
13:32myself just wait for this to finish up
13:37there's some pieces in here I have sped
13:39up just for the purposes of me not
13:42sitting up here awkwardly silent in this
13:46actually sending myself a pull request
13:48on my own project is something that
13:51often looks strange to people well
13:54what's the point of sending myself a
13:56pull request if I'm not working with
13:58anyone else
13:59well besides just practicing using the
14:01tool and practicing for when I do work
14:03with other people I don't know that this
14:05project will always remain just
14:07something I work on what if later I
14:09decide that I want to practice using
14:12github with colleagues at work I'm gonna
14:14do a quick Lunch and Learn session and I
14:17want to show this project and invite
14:18them to work on it and use pull requests
14:21with me well they can go see an example
14:23of how I sent myself a pull request and
14:25some collaboration that I actually did
14:27even with myself I always send a pull
14:30request with a concise title the title
14:32itself I often relate to an email and an
14:35email subject line I want to be able to
14:38see
14:38what that subject line is and know
14:40what's gonna be what's gonna come when I
14:41open that up and then I always comment
14:43as well or I try to as much as I can if
14:46you ever find me opening a pull request
14:48somewhere on github and I don't have a
14:50message in that first opening post feel
14:53free to comment on there and tell me
14:55otherwise art that I should go back and
14:56edit it and now this pull request lives
14:59up there forever
15:00so this isn't some email chain or some
15:04conversation that happened before a new
15:06developers started someone new came in
15:08saw this piece of code change and said
15:10what was the motivation behind this how
15:13did we do this why did we do this change
15:14you have a URL that you can specifically
15:17take and send it to them say here's the
15:20conversation that we had here's why we
15:22made that change and if they want to
15:25question that change further they should
15:26comment on that floor request we've
15:28often said a URL is forever and then
15:31Beltre who I believe is speaking
15:33tomorrow or later today talking about
15:36github pages
15:37he'll saying some of his stocks if you
15:39like it put a URL on it instead of
15:41putting a ring on it so I kind of
15:44believe that if you want to remember
15:45something put it in an issue put it into
15:47a pull request and you can always get
15:48back to it later so that's one way you
15:52use pull requests but how do you use
15:53them well a lot of people here already
15:55know how to use pull requests so I'm
15:57pulling you through this and I'm getting
15:59everyone to a baseline so that we can
16:01talk about how to use them well there's
16:04actually a research paper that I found
16:07and friends pointed me pointed out to me
16:09talking about some pieces of a pull
16:12request that actually allow it to be
16:14merged faster and more often especially
16:16when submitting it to other people so of
16:21course the emphasis here is mine but the
16:24two things I want to I want to look at
16:25here the shorter it is that the changes
16:28the shorter that changes are the faster
16:30it will be reviewed and I think we can
16:32all agree with that right if if someone
16:34submitted something to me and said hey I
16:36have this thousand page document I need
16:38you to review by tomorrow I need you to
16:43find every little change that happened
16:44would you honestly look through all
16:46thousand pages of
16:47imagine any lawmaker out there who's
16:49going back and forth with some edits to
16:51some law that they're voting on you're
16:54telling me that they are actually going
16:56through all pages making sure that no
16:58one's snuck in and they edits that they
16:59didn't understand I'm sure they do and
17:01I'm sure they have a lot of AIDS but man
17:03how much easier would it be if they just
17:05had a DIF on github in a pull request
17:07actually for you that's my dream that's
17:09what I would like and then the the
17:12second the second piece of that is going
17:16to be that CI piece so all right little
17:20Madge ination experiment here and close
17:22your eyes if this helps you but imagine
17:24you're at your office and and you're
17:26working on some code and you song on
17:28your Kanban board or some issue popped
17:30up in a bug tracker and you say I'm
17:33gonna go work on this I'm gonna create a
17:35pull request I'm gonna create some
17:36commits and I'm gonna work like Brent
17:38just told me to and like the training
17:40team at github advises so you see the
17:43future come in you start working on it
17:45you all right your laptop you're at work
17:48late you maybe go home you continue to
17:49work at it and you spend all night and
17:52then by the end of the week or maybe at
17:54the after a few days you send that as a
17:57pull request yes I did it I sent my
17:59first pull request or this is my 15th
18:02pull request but you realized someone
18:06beat you to it maybe Rachel beat you to
18:09it because she had that one little
18:11change to start discussing maybe she
18:12just edited some some text somewhere for
18:15the documentation change and then
18:17started building the feature she opened
18:19that pull request right away and that's
18:21another big barrier people have to
18:23sending poor request well not quite
18:25ready with this change yet they're gonna
18:28judge me on the way this looks and they
18:30may but you're gonna be better at it
18:33they shouldn't judge you harshly they
18:34should be there to help you write your
18:35code better
18:36so Rachel starts her pull request she
18:39brings in Lynn and she brings in Sam and
18:41she brings in Matt whoever it may be and
18:45they talked to her they used app
18:46mentions they're collaborating and
18:48talking to each other about this is
18:50wrong over here I would change this this
18:52is in our code style and they actually
18:54improve the quality of code for not only
18:56that developer Rachel in this case
18:58or every single developer who comes in
19:00after this maybe Rachel ends up being a
19:02manager and a new person comes on board
19:04is a little nervous about sending pull
19:06requests as well she can look back and
19:08say here's my first full request I got a
19:10lot of help and this is how we should
19:12work - so I mentioned the other piece
19:17there being the CI pipeline and people
19:19read pipeline I don't know how the hell
19:21to set up a CI pipeline what even is CI
19:24we're not going to really worry about
19:26setting up a pipeline at least when I
19:29think of this I don't I don't worry
19:30about any of that I don't want to set up
19:32any infrastructure but all I want is my
19:34test to run automatically I want to
19:37start some change out and when I push it
19:39to github I don't want to run those
19:41tests myself I want those tests to be
19:43running and present it into pull
19:44requests because if they're there
19:46they're part of the story of that
19:47feature and you'll be able to see as
19:49each of these changes come in as there's
19:52collaboration back and forth maybe tests
19:54fail maybe someone suggests you make a
19:56change and now tests pass but someone
19:58else suggested you make another change
19:59and now you see it fail again so having
20:03CI run automatically was one of the main
20:05parts of this research paper it said as
20:08a software developer is accepting pull
20:10requests you have many other factors and
20:11they mentioned how complicated could be
20:13it could be an open-source maintainer
20:14but also have their day job so they only
20:17look at those pull requests when they
20:18get home at about 5:00 or 6:00 p.m.
20:20maybe they have a family maybe they have
20:22extra stuff that's on top of their mind
20:24if they don't have to run tests for your
20:26code that's going to help them trust
20:28your code a whole lot better and if
20:30you're the maintainer and you don't have
20:32CI hooked up use some CI service it'll
20:35allow you to actually run those tests
20:37right away now of course this allows us
20:40to or we had to have kind of a testing
20:43first thought process here and that's a
20:46that's an important one to have and
20:48you'll have to start implementing that
20:49as well and earlier Chris talked about
20:52our integrations directory so announced
20:55this morning we have many partners who
20:57we can just plug and play into github
20:59for CI
21:00in this paper they talked about Travis
21:02CI of course one of the sponsors here as
21:04well and that's the one that I use
21:06because I think it's really easy to set
21:08up so this next a little bit
21:11we're gonna talk about opening a pull
21:13request and we're going to see how do
21:14you just quickly add Travis to it so
21:16that it runs the tests that are already
21:18inside this application this is just a
21:20real quick example Ruby application it
21:23just has some simple tests to it but I
21:26wanted to show a little bit of what that
21:27looks like
21:28so on my repository I start out and I
21:31just go over to my web hooks and
21:33services page I could have gone directly
21:36to the integrations directory and added
21:38that project as well then once on github
21:41are sorry once on Travis I can actually
21:44just enable the CI for that particular
21:46repository and then when I go and
21:50actually build my features which I speed
21:52through here a little bit adding an
21:54additional test of course copy and
21:56pasting that in to see that that test
21:58fails I can actually see how the CI
22:01actually runs on this so the important
22:03part is I'm adding a little test in
22:05there and I open my pull request and
22:08then we'll see the test start running on
22:10Travis's infrastructure we'll see one
22:12fails and then the next one fails but
22:14let's go see the details of this you
22:17start having people able to dive into
22:18where is this test actually failing I
22:21don't have to actually go look at it
22:22myself run it locally and comment to
22:24them I can link them to the Travis build
22:27status and see that hey this failed on
22:28line number 17 we actually need to
22:31include this variable which is actually
22:33what's happening here so I had this
22:38little variable in just so that test
22:40passes kind of test first or test-driven
22:42development there I make that commit and
22:45once I commit back to that branch and
22:47revisit that pull request will see the
22:49CI status now kick back off again so you
22:52have a failed test at first and now you
22:54have a bunch of pending tests as those
22:56that build the event kicks off and goes
22:58over to Travis now of course I am
23:02actually able to merge the pull request
23:03even when those tests are running or
23:05failing which we'll look at here in just
23:08a minute so my test pass everyone
23:10looking back at this in the future or
23:11actually if you wanted to go visit this
23:13project right now you could actually go
23:15look at that and this PR is there just
23:18don't look at the timestamps of when
23:19this actually happened
23:20it was last night cool so that's pull
23:26request
23:27so in summary use pull requests right
23:29that's a big piece that I'm kind of
23:30trying to hammer home here and open
23:32those pull requests early don't wait
23:34until you think your feature is complete
23:36because what if someone else beats you
23:37to the punch
23:38use the pull request right away so you'd
23:40have something to talk about I'll often
23:42open a pull request just by changing
23:43documentation or I don't want to just
23:46change whitespace and then instead of a
23:47pull request but change something to
23:49talk about and then send the pull
23:51request and then you see I to actually
23:53ensure your pull request is merchants
23:55confidence we have many partners out
23:57there to integrate with their github
23:58accounts get your repositories a lot of
24:01them are free if you want to do a hosted
24:03solution you could do those as well
24:07raise your hand if you love meetings
24:11great couple people a couple people seem
24:14to love meetings well we'll meet after
24:16this to talk about it but I don't know
24:19too many developers who can tell me with
24:21a straight face that they would rather
24:23spend their time in a meeting than
24:24actually shipping code what are you
24:27doing at a company if not to change the
24:30software or make the software better
24:31make someone's lives better so some say
24:35that if tests are failing you shouldn't
24:38be able to merge it into production and
24:40and there should be a gated check-in for
24:42that we shouldn't be able to actually
24:43merge it and that's that's fine that is
24:46one way of code review but I think it
24:49should be more than that and I think
24:51you're done of all humans and if you can
24:53guess the c-word I'm about to use
24:54collaboration so Jeff Atwood has done
24:59many great things including being the
25:02co-founder of Stack Overflow and I don't
25:04know if I'd be at my job today if it
25:06wasn't for him and being able to search
25:08things on Stack Overflow in fact if you
25:10use atom as a text editor I think
25:12there's a package that allows you to do
25:14a pop up type in Stack Overflow and copy
25:16to your clipboard from there and paste
25:18the code right in so we're making it
25:21easier to share and collaborate our code
25:24secrets I guess on and co-working there
25:28so but he has a point here peer reviews
25:32are important and I'm not saying don't
25:33do
25:34reviews when I start talking about oh
25:35you have your deployments and your work
25:38over here and you have your your code
25:40review over here all I'm saying is don't
25:43split them up too much peer review is
25:45important so I gotta really stop doing
25:50that so peer review is important and how
25:53you do it is important and I think you
25:55should be talking to your co-workers to
25:57actually do peer review at github this
25:59is how we do it there's a pull request
26:01open
26:02I am mention the appropriate team
26:04members I bring people into the
26:05discussion and they'll actually look at
26:07my code and they'll say they'll use the
26:09+1 emoji and say yep that looks good
26:11that looks good or that looks great go
26:13ahead and merge that in to into
26:15production or go ahead and deploy that
26:16and they usually help out with that as
26:18well and so here I'm just going to open
26:22a pull request and our developer reaches
26:25out to the github teacher account so
26:26again if you've ever been in any of this
26:27training classes or may be familiar with
26:29the teacher account here the teachers
26:31actually commented already and just
26:32thanked us for this comment for this
26:35method something really simple and all
26:37I'm doing is talking back to that person
26:39letting them know hey I've seen your
26:40comment that looks great I'm glad you're
26:42talking to me I don't want to leave you
26:43hanging so I'm just gonna say this looks
26:45good thank you for reviewing I'm gonna
26:47go ahead and merge this now I'll go
26:50ahead and merge that pull request and
26:52clean up our branches of course
26:54afterwards by deleting the branch but
27:00that's really easy for me to say we have
27:02a deep entrenched culture of don't merge
27:05without anyone reviewing your work and
27:08if you do we kind of talk to you and we
27:10get better at it but people want
27:12stronger see I are sorry
27:14then what stronger code review and and
27:17luckily we came out with protected
27:19branches just a short time ago how
27:20convenient for this talk so protected
27:23branches allow you to pick a branch
27:25within your repository and say I don't
27:28want anyone to force push this branch I
27:30didn't want anyone to accidentally
27:31delete this branch I don't want anyone
27:34to accidentally commit on the web side
27:35and in case instead of sending a pull
27:38request and I also need these tests or
27:41these required status checks to pass
27:43before I actually
27:45this code in the other thing that's nice
27:50for me is maybe I don't want to use a CI
27:54service or maybe there's not a tool out
27:56there that allows me to do more rigorous
27:58code review using our API you can
28:01actually report back the commit status
28:03to fail the test so maybe you're you're
28:05into using the API and you want to write
28:07something else up on your own you could
28:09actually build a web hook on top of your
28:11repository to receive some of that data
28:13next time someone pushes code parse
28:16through all the comments on the pull
28:17request if you don't see any +1 emojis
28:20attached of failing status to that
28:21commit then inside protected branches
28:25you could say this is one of the things
28:27that is required to pass and that sounds
28:29great and I would have loved to build it
28:32before this but I didn't there is a tool
28:35that an open-source tool actually
28:38there's an open-source tool out there
28:40that actually allows me to do this for
28:42me so we'll take a look at that in a bit
28:44but first let's actually set up
28:45protected branches so any repository
28:48that you have admin access over you can
28:51actually go over to these settings and
28:53then branches tab once there to enable
28:56protected branches now for me I care
28:58about protecting master and I need
29:02status checks to pass and also that
29:04important piece right there the include
29:08administrators because I'm not special I
29:10don't need to jump through I'm not
29:12getting around this topic at all I don't
29:15want to skip the required status checks
29:17so we need to make sure that's added and
29:19of course I sort of used Travis
29:21previously that popped up there and I
29:23can add that so protected branches
29:27required status checks as easy as
29:29clicking a couple checkboxes on your
29:31project once you have CI or some other
29:33tool integrated but I what if I want
29:37sign-off right I kind of mentioned
29:38building that with CI or rather building
29:40out with the API and I don't actually
29:42want to do that there's a really nice
29:45open-source tool that I've been familiar
29:48with or seen for awhile and recently
29:50integrated into project a couple days
29:53ago and actually set up myself well I
29:55kind of set it up there's a really nice
29:57deploy to Heroku but
29:58if you need to talk to the wonderful
30:00folks at Heroku over by the deploy stage
30:02that would be perfect this is one of my
30:04favorite features that have come out
30:05within a long time I was able to go to
30:07this project click that button it spins
30:09up an instance for me free I can set
30:12some variables and have that running for
30:14myself up in Heroku so I don't actually
30:17have to worry about taking this
30:18open-source code running it on AWS and
30:22again I just kind of wanted to do a
30:23quick shout out if this is something
30:25you're interested in looking at it's at
30:27github comm / review ninja slash
30:29reviewed ninja or reviewed ninja just on
30:32the Internet
30:33so let's connect review ninja with an
30:35instance that I already have running on
30:37Heroku so all I'm gonna do is visit that
30:41URL that I have running sign in with my
30:45account as the github developer there
30:47authorize the application that's the
30:50same flow you'll see if you start using
30:51any of those integrations that we have
30:53out there as well and once I'm signed in
30:55I can select my repository that I
30:58actually want to start using code review
31:00for and again looking on that page there
31:03we'll see that there's no pull requests
31:04currently open so now let's actually
31:07look at opening a pull request and make
31:09sure review ninja is going to be turned
31:10on for that protected statuses so we see
31:13that pull request open we see required
31:15on Travis but not review ninja so I'm
31:19gonna go into my settings and just
31:22enable that just a simple check box once
31:24that's connected to my repository
31:25refreshing this page so it says that
31:29that's now required and my merge button
31:31has been disabled so from here on out
31:33every single every single pull request
31:35turn of this project needs review ninja
31:38and more specifically in review ninja
31:41which we'll see in a moment not only do
31:44I not only can I configure how many
31:46people need to give it a ninja star or
31:47for the better or worse a +1 to merge it
31:50there's also a number of things inside
31:52review ninja to mark something as
31:54needing to be reviewed or you need to
31:57fix this problem that will also fail on
32:00the status check which i think is quite
32:01nice so the PR has been open
32:06excuse me the pier has been open and
32:09that teacher can now actually go to that
32:11pull request and rather review that the
32:14review ninja and they can they can find
32:18the pull request and comment on it maybe
32:20find if there's any bugs we see here
32:23that the markdown for the teacher's name
32:24is improper so the teachers just going
32:27to comment and say that's not actually
32:29the link to my account you should fix
32:31this before you merge it in fact I don't
32:34want the developer to accidentally merge
32:36this so I'm gonna mark this as needing
32:38to be resolved one thing that's really
32:41nice about this connection you may say
32:43well I don't want the collaboration to
32:44happen on there if you ninja I want it
32:45to be your be on github this comment
32:49actually appears in line on github so if
32:52your developers just live in github and
32:53your project managers or your QA team
32:55lives and review ninja you can kind of
32:58the communication and like talking
32:59between the two is across the board so
33:03that comment goes through and so now the
33:06student can go back and actually edit
33:08that go into that line specifically make
33:12that change review ninja can also be
33:14enabled to send notifications out to
33:16people for when something is needing to
33:18be reviewed or resolved and fixed so the
33:22student comes in fixes that goes back to
33:25review ninja changes that drop down to
33:28say yep this has been fixed that's been
33:29resolved
33:30so we we see on that required status
33:33check it doesn't say that there's any
33:34issues for a review ninja now and then
33:37this important part yes there may be an
33:39email that goes out to the teacher but
33:40you should talk to them let them know
33:42that you actually did this change don't
33:44just expect them to receive an email
33:45talk to them in github to actually
33:48notify them of this change and of course
33:52kind of close this this little piece out
33:54will see the teacher updates the student
33:58and tells them to go ahead and merge
33:59this change we see that merge button on
34:02review ninjas actually green now because
34:04not only see I passing they gave the
34:06star and there's no resolvable comments
34:08left and the teacher will just speak
34:11back to and collaborate back with the
34:13developer letting them know hey cool
34:16that's great thank you for talking to me
34:17I'm going to
34:17just message you back I got a bug trying
34:21to hit enter there so that looks great
34:24and the student then could are that
34:27starting up the student the developer
34:28could then go and merge the pull request
34:31all right so what have we learned we got
34:34a couple things code review being a big
34:36piece of what I just discussed there's
34:40no one way to do code review if you have
34:42no code review do something enable a
34:46culture within your company of talking
34:48to each other on these pull requests
34:49bringing people into the discussion
34:52asking them to review your work I
34:54realize two people could kind of buddy
34:56up and cheat and just say oh I'll always
34:57review your work you always review mine
34:59but if you see that happening talk to
35:02them about it build a better culture
35:04protected branches can help ensure
35:06things if you're maybe within a HIPAA
35:09compliance company or you work at some
35:10bank and you need some more rigorous
35:12code review for actual being audited
35:17maybe by by auditors or has your code
35:20review process going needs to be
35:21stricter because we're a bank that's
35:24possible as well so all this coming down
35:29to the conclusion of what is the github
35:30flow so as I mentioned in the very
35:32beginning with that that picture the
35:34get'em flow I'm not gonna read the whole
35:36slide but it allows us to work and be
35:39flexible with the actual code review or
35:42pull request or workflow in general that
35:44we want to use the reason why we teach
35:46it within getup services is we want
35:49people to have a great baseline they
35:51want to plug something into it they can
35:53do so so code review and talking to your
35:57team assuming it the things that work
36:00best for you and ensuring this developer
36:01czar running good quality code some
36:03people say well man we're doing these
36:05code review check-ins now and people
36:07have to +1 their code it's taking too
36:10long
36:10well the quality of the what they write
36:12will actually start to improve things
36:14will speed up a lot faster I've seen it
36:16I'm sure you've all seen it as well and
36:20there used to be this philosophy that I
36:21heard other development companies or
36:23such as software departments at
36:25companies say
36:26move fast and break things I think
36:28actually Facebook originally said that I
36:30think I saw in the news recently they
36:32said that's not their motto anymore but
36:35I like that idea
36:36so if traditionally your customers are
36:38used to something coming out every four
36:40to eight weeks well what happens if
36:43there's a bug that was introduced when
36:44they released it do they have to wait
36:46four to eight weeks to get a fix on that
36:48how many people are being affected by
36:51that bug is that 40,000 people that's
36:53had a million people I don't know how
36:55many people have downloaded certain iOS
36:57apps but that's a lot of people you
36:59could be affecting why don't you get
37:00that code out faster sure maybe there's
37:03a bug introduced and maybe now you need
37:05to do a retrospective on that that code
37:08that it got introduced talk to that
37:09developer find out how to make that
37:10better but what if you could make that
37:13fix not take 8 weeks what if it took 2
37:15days what if it just took a week could
37:18you cut in half the number of people
37:20that were actually affected by that bug
37:21that'd be it'd be quite an improvement
37:23so maybe you have something like this
37:26where your developers meetings are
37:28unfortunately not coming through very
37:30clearly but I'll post these slides you
37:32can all see this on the left side or
37:34current you have a lot of calendar
37:36invites or a lot of meetings inside your
37:38calendar your developers not spending a
37:40lot of time coding you want them
37:42spending more time coding so that they
37:44can actually ship their software so they
37:46can make changes and actually iterate on
37:47what they're doing we don't want them to
37:50actually be spending time doing that we
37:52should have that code review happening
37:54instantly right when that pull request
37:56is open that should be part of your
37:58development cycle so when one just a
38:01call out here one piece that we haven't
38:03actually discussed and we won't discuss
38:04is that deployment piece there's a whole
38:07section on that happening over there I
38:09wanted to focus on the collaboration
38:11piece of this to actually let us build
38:14that culture to then prep us to be in a
38:16perfect position to decide how we're
38:18going to deploy and if you want to work
38:20a little bit more on deploying you can
38:22go to the deploy section of our
38:24integrations page pick from any number
38:26of these providers to actually pick the
38:29solution that's best for you so some
38:33people say pull requests slow down their
38:35development flow well I just want to
38:37commit to master why can't I do that
38:40because there's zero collaboration that
38:41way you're not going to become a better
38:43developer by working by yourself
38:45people say code review is gonna take too
38:47long I don't want to spend time doing
38:49code review well you'll become a better
38:51developer as you do code review in one
38:54form or another and talk to your
38:55colleagues and work with them and then
39:00lastly I wanted to show this one more
39:01time to talk about these steps create
39:05that branch start making some work
39:07create a pull request talk to your
39:10colleagues and that collaboration piece
39:12after the pull request is there right
39:14before that ship it squirrel right
39:16before you decide to ship this code out
39:17to millions of people talk about the
39:19change find out what's best is there
39:22another set of eyes looking at this
39:23problem from a different way work on
39:25that and so lastly kind of with the
39:32github flow using pull requests talking
39:35to your teammates making sure the code
39:37is well tested well reviewed
39:38everyone's gonna start becoming better
39:41and as JFK I believe said a rising tide
39:45lifts all ships so raise the quality of
39:49code written at your company work better
39:51with your co-workers work better with
39:53the open-source community just make
39:55everyone better thank you
40:07and just a quick note if you'd like to
40:10send up for some github services kind of
40:12one-on-one sessions or some sit-down
40:14sessions with them right in front of the
40:16build stage the get up services team is
40:19sitting there they have a lot of open
40:20slots to sign up with take a look at
40:23that sign out talk to them maybe do it
40:24over lunch or whatever is most
40:26convenient for you if you do want to
40:28have a meeting with me outside this this
40:31session I'll be around you can reach me
40:34at a de dust onto the slide as well but
40:36you can reach me just basically at Brent
40:40beer or Brent at github comm if you want
40:42to talk to me about some changes thanks