Search
Talks
How GitHub Uses GitHub to Build GitHub
Edit
#github
#continuous-integration-ci
#developer-workflows
#agile-development
#pull-requests
#software-development-practices
Summarized using AI

How GitHub Uses GitHub to Build GitHub

Zach Holman • September 29, 2011 • New Orleans, Louisiana • Talk

In this talk presented at RubyConf 2011, Zach Holman, an employee at GitHub, discusses how the company utilizes its own platform to streamline development processes. The title "How GitHub Uses GitHub to Build GitHub" hints at a deep exploration of GitHub's internal workflows rather than merely the tool itself. Holman emphasizes the importance of fostering an environment conducive to asynchronous work, which allows developers to operate in their ‘zone’ without unnecessary interruptions.

Key points include:

  • Minimizing Overhead: GitHub aims to keep its development process light and devoid of excessive meetings and deadlines, thereby enhancing productivity.
  • Asynchronous Work: The company encourages asynchronous communication through chatrooms, allowing discussions to be logged and retrieved as needed, thus maintaining a clear flow of information.
  • Branching Strategies: Holman outlines GitHub's approach to using branches in a straightforward manner, which avoids the complexities found in many organizations. He mentions that GitHub only uses a master branch and feature branches, simplifying the deployment process.
  • Pull Requests as Code Reviews: Pull requests are employed as the primary method for code reviews, which allow for synchronous discussions around code while avoiding lengthy meetings. This system incorporates input from all team members, including designers.
  • Issues: Holman discusses how GitHub manages issues simply and effectively, using them for bug tracking, feature requests, and keeping a to-do list to enhance productivity.
  • Automation and Tools: He shares the significance of automating processes to save time, including the use of Hubot, a chatbot that helps streamline internal tasks and communications.

Through anecdotes and examples, Holman illustrates these strategies in action, sharing insights into specific pull requests and the importance of collaboration across teams. The talk enhances understanding of how GitHub can serve as both a tool and a model for efficient software development, stressing the importance of simplicity in tools and processes.

In conclusion, Holman's insights reinforce the importance of continuous evaluation and refinement of work processes to ensure simplicity and efficiency in software development.

The main takeaways from this talk are the value of reducing complexity in workflows, fostering collaboration through transparency, and leveraging tools effectively for asynchronous communication and automation.

How GitHub Uses GitHub to Build GitHub
Zach Holman • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 13, 2011
Announced: unknown

Build features fast. Ship them. That's what we try to do at GitHub. Our process is the anti-process: what's the minimum overhead we can put up with to keep our code quality high, all while building features *as quickly as possible*? It's not just features, either: faster development means happier developers. This talk will dive into how GitHub uses GitHub: we'll look at some of our actual Pull Requests, the internal apps we build on our own API, how we plan new features, our Git branching strategies, and lots of tricks we use to get everyone — developers, designers, and everyone else — involved with new code. We think it's a great way to work, and we think it'll work in your company, too.

RubyConf 2011

00:00:17.119 hello Ruby conf how's it
00:00:23.400 going so you guys ever build that thing you know that thing I'm talking about where you're at work and you're hacking
00:00:28.760 on something that library that thing you're building that side project and you're working on this thing you're working on this thing you're working on
00:00:34.120 this thing and then all of a sudden you show your cooworker you're like hey check out my thing and cooworker like whoa that thing is awesome so you're
00:00:40.520 feeling kind of good you're strutting around you go up to your boss you're like hey boss check out my thing and your boss is like whoa the is that
00:00:47.360 thing and you're like well you know protect the servers from ever crashing and he's like I don't care about that thing I want you to work on this one it
00:00:54.120 will increase our user conversion ratio and you're like okay so we go back to work on his thing you don't know how to
00:01:00.239 work on his thing so you call him up like I don't know what the you're talking about how do we go from here so he's like all right let's get a meeting
00:01:06.320 so it's you your cooworker your boss your boss's boss your boss's boss's boss and something called a stakeholder and you're working on this thing and no one
00:01:12.200 knows how anything's going this meeting is going terribly and eventually you're like all right I'm just going to go do my own thing so you go back you start
00:01:18.159 working on this thing working on this thing you show your cooworker and co-worker's like wow that's something and you're like yeah I know so you keep
00:01:25.400 going you keep going and then you're like all right I'm just going to deploy this thing and someone comes up to you and they're like wait a minute I've been working on my thing for four times as
00:01:32.000 long I got to deploy first so like all right you deploy first then I'll go he deploys and then your time to deploy and
00:01:38.040 you're about to deploy all the servers crash because the first thing you're working on never got
00:01:45.920 deployed something is up this is not surprising software
00:01:52.880 development is difficult software development is hard and we all work in this industry we all understand you have
00:01:58.159 to deal with people you have to deal with people's expect ations you have to deal with deadlines you have to deal with imperfect information this stuff is
00:02:04.439 difficult and nothing I say today or anybody else will suddenly magically fix
00:02:09.959 everything but there's a lot of things you can do to improve your process and make things less painful you know I've come to a lot of
00:02:16.640 these conferences and I'll sit and someone will go up on stage and talk about agile or test driven development
00:02:21.680 or bdd or whatever is invogue in that current week and I can sit and be like yeah yeah that makes sense writing test
00:02:28.040 first is really cool I should do that yet and then I'll go home and it it it doesn't work for me like the pro it
00:02:34.440 feels so heavy the process is just not working for me it pulls me on my zone and for the longest time I was sort of
00:02:40.280 like well you know this test driven stuff doesn't work for me or behavior-driven development doesn't work for me and this whole slew of stuff
00:02:46.920 doesn't work for me like why am I so strange um and I thought that was just sort of a bummer and you know I see all
00:02:54.400 these people happy with all these Agile development strategies and that's cool because software development is hard if
00:02:59.440 you find that works for you stick with it but I always thought there had to be something else that was a lot better
00:03:05.280 that made me really enjoy working with myself and with other people and I think I finally figured out um you the last
00:03:12.400 few years of how I've been working has been awesome and that's what I want to talk about today so the title talk is
00:03:18.120 how GitHub uses GitHub to build GitHub the secret is this is not about GitHub
00:03:23.159 um okay I'm lying I use GitHub three times in the title it's slightly about GitHub but what I mean by that is not
00:03:29.280 about the tool GitHub it's more about how we work um our processes our workflows um how that stuff is working
00:03:36.720 well for us um and I think like I would give this talk if I worked at Twitter or I would give this talk if I worked at
00:03:42.280 Facebook or anywhere else because I think this is a really important way to work um and that's what this talk is
00:03:47.439 about it's about how you can use not just the tools but the processes that we've sort of discovered through lots of
00:03:53.840 work at GitHub um to help build your own product so I am Zack hman um homeing on
00:04:00.200 Twitter homeing on GitHub um I work for GitHub
00:04:06.640 uh uh I'm employee number nine so I've worked there for the last year and a half so I've sort of seen how we've
00:04:12.560 scaled up from nine employees to 20 to 30 now we're at 42 um so I've been able
00:04:18.199 to see what has worked for us and how we've had to grow um throughout time to deal with all these new people new processes but I think more importantly
00:04:24.440 I've also figured out I've been able to see what we haven't changed over time what our IAL assumptions were and have
00:04:31.240 worked for us as we've continued on and grown as much as we have um so first of all I want to talk
00:04:37.120 about very slightly how we actually work because otherwise these slides will probably seem insane um but I mean we
00:04:44.240 work asynchronously so what is this actually mean um I looked this up in a dictionary and the dictionary definition
00:04:49.520 was you can do without needing to pull me out of the Zone I I read really edgy
00:04:56.520 dictionaries but I mean this is this is what it's all about it's like development is hard and we want to get
00:05:03.520 our employees in the zone as much as possible whatever the Zone means the Zone the gro the groove or you know
00:05:09.680 whatever you want to call it it's that time where code just sort of flows for you it's it's where you feel really into
00:05:14.880 it and every time you've had a job where you have to get in at like 8 in the morning arbitrarily and you try and
00:05:21.160 force yourself in that zone that's the time when you realize that like it just doesn't work to try and force people to
00:05:27.759 get in there it it has to come naturally so we do a lot of stuff to try and Foster this sort of environment one is
00:05:33.479 no meetings um I I can count the number of times on one hand I think where we've actually sat down at GitHub to try and
00:05:39.319 puzzle stuff out um because I think meetings are just kind of a waste of time in a lot of cases no one knows how
00:05:45.280 to run them there's too many people and they always run for six or seven times as long as they
00:05:52.400 should yes we should meet after this to discuss that
00:05:58.440 clap um secondly there's no deadlines um there's there's no feeling like you
00:06:05.880 got to get something out because some boss is telling me that next week is the day whatever the day happens to be if it's done that's good um that doesn't
00:06:13.400 mean you can't just sit back and not ship anything we have a big culture of get stuff out as fast as possible but
00:06:19.319 that's different from get stuff out as fast as possible because someone arbitrarily discovers a date that you need to hit the third one ignore pings
00:06:26.479 is kind of a weird phrase but we sort of have a culture of if I need help with
00:06:32.080 something I can ping someone else at GitHub and say Ryan you know can I get some help with whatever I'm working on
00:06:38.520 and there's sort of a culture of I don't necessarily need to expect him to respond to me because again like we
00:06:44.199 don't want to pull people out of the Zone arbitrarily like he'll see it come up and be like Oh Zach is trying to talk to me let me just get this figured out
00:06:50.759 and then I can attack it later um I think that's actually really helpful and that's the the the constant disruptions
00:06:55.840 you get in the workplace is a real pain in the ass and there are way if I really need his help I can you know run over
00:07:02.319 there and steal him but um for the most part people don't have critical stuff
00:07:07.360 every single 10 seconds so getting back down to what this actually means for us one we do all
00:07:14.039 of our work in a chat room if it's you and me at the office at 2 in the morning and we're on the same table and no one
00:07:19.080 else is around I'm still going to talk to you over campfire because the second Point everything is logged um you know I
00:07:25.840 can step out for lunch and then come back and see everything that's happened in the company because it's all in the transcript right there waiting for me
00:07:32.199 that stuff's really powerful um we've all run into the time when like somebody verbally tells you something like this
00:07:38.759 is how you set up the email when I'm gone for a week and then all of a sudden like a week later you know you were at
00:07:45.599 Ruby conf and you were drinking the entire time you can't remember what the heck he was talking about if this is actually logged if it's in an email if
00:07:51.039 it's in a chat transcript you can go back and actually figure stuff out and then thirdly time flexibility um again
00:07:58.360 like you're not going to find me at the office at 8 in the morning because that's just not how I work um and then we have the same amount of people at
00:08:04.039 GitHub who do do that they get there at like 700 or 8 in the morning because that's how they work that's how they get really excited about stuff and for
00:08:11.000 GitHub that's that's uh it's big that we get people to work as they want to work
00:08:16.639 naturally um so I mean I wrote three posts on this if you guys want to check it out um
00:08:23.400 whatever I don't want to self-promote I'm already doing enough in this talk okay
00:08:30.400 what are we doing today um we're going to talk about polar request and branching I think this is uniquely what sets GitHub apart from a lot of other
00:08:37.159 companies um then we're going to talk about issues a little bit we're going to talk about oaf as identity and we're going to talk about Hooks and hubot so
00:08:44.080 first of all pull request and branching um this is something that one I don't think a lot of people necessarily uh use
00:08:51.440 to their full potential um you guys got some weird branches um I do a lot of
00:08:57.120 like customer support sort of stuff at GitHub I do this uh particularly with a lot of Enterprise large companies and
00:09:03.279 this is one of the the the pain points like people have really weird get branching techniques and I think it
00:09:08.320 really screws you up down the line um for example uh one thing I've seen is like somebody starts out with a master
00:09:13.959 branch and then they're going to deploy something else and so they cut a deploy branch which is cool and then that gets
00:09:19.800 deployed and then they cut another Branch off that deploy branch and they cut another one off of that depending on when they're deploying they cut another
00:09:25.320 one another one and first of all you don't know where the heck the state of current development is and that's just
00:09:30.399 frustrating it's just complicated it's needlessly complicated um another one I see a lot particularly in very large
00:09:36.440 companies is this workflow like you have one repository that everyone's working on you have a group of trusted
00:09:41.760 developers who get full readwrite access to this repository and that's cool then
00:09:46.839 they have a bunch of other people I'm going to call them shitty
00:09:54.600 developers I'm G to call them shitty developers because they they they apparently aren't trusted enough to be
00:09:59.680 the trusted developers and there's there's already this arbitrary guideline of these guys aren't cool enough so we got to like not hand them the keys but
00:10:06.320 then that means that they have to have their own forks and then they push their forks and then they push that back to the trusted developers that means the
00:10:12.560 trust developers job is to deal with these other Forks coming in and either put it back into the repo or say no you
00:10:18.040 guys are actually shitty redo this and then they got to pull down from the repository if you see a workflow like
00:10:23.959 this in your company something's really messed up you don't want complexity keep your
00:10:29.760 branches simple um this is the thing that it's it's the very base of your foundation for building a product if you
00:10:36.440 have a really complicated um Foundation it's going to lead to a complicated product um so how do we do this we have
00:10:44.399 a master branch and then if you're working on something else you cut a new branch and that's it and then when that
00:10:50.399 Branch goes back it'll go back into Master like this is the workflow that really makes a lot of sense to us it's
00:10:57.399 very simple there's no arbitrary like trusted shitty developers I would be the only one who's in the shitty developer
00:11:03.240 at GitHub anyway um but I mean everyone can push everyone can deploy um if you
00:11:08.360 have access to GitHub GitHub on GitHub um you can push you can deploy to the site uh our designers deploy a whole
00:11:15.440 bunch um which we think is a really good thing um and it also frees us up from
00:11:21.560 micromanaging everyone if you are that trusted developer then you have to deal with code review all the time you have
00:11:27.839 to deal with them you know is their code coming in can I merge that you lose the
00:11:32.880 accountability of those other developers because they just push to you and assume that it's going to be
00:11:38.519 fine so Master is always Deployable for us always like that is like the one
00:11:43.760 Ironclad rule Master is always ready to go out and we can deploy it at will and that's sort of our safe fallback if
00:11:49.360 something happens we can always go back deploy master and we're good um this is good because we deploy 10 to 40 times a
00:11:54.959 day um we like small incremental deploys because then you know exactly what
00:12:00.519 changed and what broke if you push something bad um if you're really nervous you can deoy a staging we have a
00:12:06.440 separate staging environment uh you can deploy to a or you can deploy just a branch and then see how that goes you
00:12:12.399 can also deploy just a you know just deploy to like two servers that we're actually using which is really helpful
00:12:18.079 because then you actually get it out in production you can test it out and you can check out exceptions see if anything's happening and then you can
00:12:24.079 roll back to master if something does mess up um this is sort of fun for us it's like Twitter driven development um
00:12:30.760 you guys complain a lot if we break something so you can push out to a subset of Branch boxes and then like see
00:12:36.680 if people are complaining and if not um then you can roll back because
00:12:43.399 Master is always Deployable so keep your branches simple
00:12:49.320 things get really complicated if you make your git branches simple or complicated you guys are I know
00:12:55.839 what you're thinking you know if you're deploying all this much if you let design ERS in your code everyone hates designers here because they're all weird
00:13:03.199 um you know what about code quality and that's a really good point like you don't want code quality to go out the
00:13:08.399 window because you want to be really quick so for us the solution is pull requests um and these are really awesome
00:13:17.000 this is sort of the the the the central part of why I feel so happy about working in this sort of asynchronous
00:13:24.320 pull request World pull requests are our code review we don't have separate meetings we don't
00:13:30.279 project stuff on a screen and go line by line PO requests are where we do all this stuff I sort of lied about this
00:13:36.519 process this isn't exactly our process it looks more like this you cut a branch open a PO request
00:13:44.000 on that branch and then that goes into master so this is the whole process of how you build something at GitHub and I
00:13:49.399 think it's really simple um the big secret number one you don't need to Fork anything we see this
00:13:54.839 a lot where to use poll requests you have to Fork into another repository and then send a p requests that's actually
00:14:00.240 not the case you can do a PO request between branches within the same repository um and you can do it doesn't
00:14:06.399 have to go to master either you can do a PO request from one branch to another branch which is kind of cool um and
00:14:12.720 that's I mean we only have one fork and we all work on the same fork and it's just simplifies things a lot more um
00:14:18.959 secondly you can run your CI tests on branches other than master um this may seem sort of obvious there are some
00:14:24.800 people this is not so obvious like you can run branches all the time we have branches is um if you push a branch up
00:14:30.759 to our CI it's going to build that Branch automatically um so why are pull
00:14:35.880 requests so awesome there's synchronous they send out notifications they're accessible let's go into these
00:14:41.440 directly synchronous that means no meetings um again it's it's for every
00:14:47.759 time that you've sat in a room and you projected code on a wall and tried to go through mentally without your computer right there you can't run it you can't
00:14:54.199 get your development kit in there it it's very complicated it's very abstract and people think this is a good way to
00:14:59.399 do stuff pull requests mean you can just open that up people will see it they can pull it down bring your branch down they can commit directly to it if they see
00:15:06.440 something is wrong or they can comment on it um it's just a a much more streamlined way to to do stuff you get
00:15:12.440 better results notifications um for me this is sort of a way to get email as my
00:15:17.800 interface I'll wake up in the morning and I'll see the the Europeans and you know the Aussies have been working away
00:15:23.199 and I can quickly open up my phone and see oh this is what's happened yesterday and I don't necessarily have to dig into it it's just another interace space of
00:15:29.360 figuring out what is actually happening in the company um they're also really accessible um we involve our designers
00:15:36.680 substantially in polar requests um this isn't some sort of field where you know
00:15:41.880 the developers work in this weird developer area and the designers work over here they should work together you
00:15:47.120 should be able to evolve the code as you evolve your mockups um and we also use P requests for non-technical staff um if
00:15:53.880 you're going to build something that impacts someone else's job just send them a link and be like does this look good is this interesting to you would
00:16:00.639 you do this differently and they don't have to know the code but they can see your your screenshots that you posted your you know discussion and actually
00:16:07.560 add in their two cents um also they're historical um po request should be experiments you should
00:16:13.800 go into this and a lot of times you shouldn't actually think to yourself man I really need to deploy this or merge
00:16:20.199 this in master they can be experiments you push them out see what people think and then throw away the code like you
00:16:25.240 don't actually have to ship pull requests um there're are collective experience together um so I just want to
00:16:31.839 show a couple of art pole requests um we had this problem with status.
00:16:38.120 up.com where something would go wrong and then people would jump to the site and you guys would be quicker than the
00:16:43.399 two minutes it takes us to update Twitter or update you know whatever we're updating um so I just built a
00:16:49.120 quick little real-time thing that would just pull uh you know various important services and then add it to the status
00:16:54.480 site um so I started out basically with this just a quick print out like the
00:17:00.759 state of these services on GitHub and I didn't have to deal with design or anything because soon enough I knew if I
00:17:06.679 post a PL request someone would come in and actually design this out for me and I didn't have to contact a designer or
00:17:13.160 anything because they already saw the notification and it went really well I have a design I can start building my own stuff according to that design we
00:17:19.880 had a lot more discussion on it had some more code um and then eventually got merged it's very simple we didn't have
00:17:25.679 to sit down we didn't have to even discuss much in campfire um because it's all right here um mix your designers and your
00:17:33.320 developers I think that's really important um it it's it's a collaborative experience and just bring more people into it um also post
00:17:40.840 screenshots um and animated gifs because they're
00:17:47.360 funny um we also have a we launched a little bit ago a a more advanced text
00:17:53.120 editor with syntax highlight what's the syntax highlighting I don't know tabs work and the new one which I like um and
00:17:58.480 we built this this is in like February Kyle opened this up for codir and he did this entire pull request over I don't
00:18:04.720 know a few weeks and stuff like this and kept adding stuff fixing stuff had this all this discussion and eventually was
00:18:09.840 like this won't work close it because it didn't work it didn't work for us we had a couple other things but this was still
00:18:16.080 important because we have this whole history here for us which happened to be really good because when we added it again a couple months ago it was all
00:18:22.840 there we could recall back how we actually were thinking how you know the UI might look stuff like that um they're
00:18:29.440 really cheap just build them out and then um you know see what works what doesn't work um don't be afraid to try
00:18:36.080 to break it Hub gently um this is a PO request we've had since February hasn't
00:18:41.919 shipped yet um we've had designers in this we've had lots of commits um this
00:18:47.840 stuff's fun because whenever this does actually end up getting into Master we can go back and you know hire someone
00:18:53.720 tomorrow and they can go through this whole thing and it's all right there there's no you know meetings that no one has notes for um it's really
00:19:01.039 powerful um other fun things build a fast test Suite ours runs in uh less
00:19:06.600 than 300 seconds or so um that means it's a lot easier to Branch stuff and it's just ready to go uh make sure your
00:19:14.120 CI can test each branch um ideally automatically so you don't have to set up each branch every time um also you
00:19:21.400 can delete uh Delete the branches we keep track of all that in the P requests um so again just you know experiment
00:19:27.720 with stuff see if it works works and don't worry about it polluting your actual G repository um also that's how
00:19:33.760 you embed stuff uh in markdown this is the most important part animated
00:19:41.120 gifs so I mean use P request more um they're awesome like I really believe
00:19:47.360 this is one way that we are able to quickly build out code and get a lot of people involved in the
00:19:54.120 conversation so issues um issues are fun everybody has issues GitHub sometimes
00:19:59.840 has more issues especially this morning um everybody's seen stuff like this this
00:20:04.960 is some issue tracker which I'll be rename nameless and all this stuff sort of
00:20:10.320 makes sense I mean you have like all these you know fields and forms but like
00:20:15.919 there there's just so much stuff happening here and eventually it's just like there is some real problems with
00:20:26.039 this I mean you look back and through all this stuff and it's just like does this stuff really matter and I think
00:20:31.240 that's a good question to ask um I mean this is again not necessarily about the tool about GitHub but this is how this
00:20:37.640 is the type of tool we would use if we didn't actually own GitHub it's very simple we just have a title and description and that simplifies a lot of
00:20:45.480 things I think it's a good question to ask like can you survive on simpler tools can you work faster on simpler tools can you work better on simpler
00:20:52.039 tools people like to say yeah I build a really simple product we love Simplicity and then they go off and use really
00:20:58.200 complex development uh products to build their own product and I think that's really
00:21:04.080 confusing um one of my favorite crushes on Twitter is Merlin man um hot dogs
00:21:09.760 ladies he had a good blog post on email priorities which is um it was about email but it's very much about software
00:21:16.240 development in general said a priority is observed not manufactured assigned otherwise it's necessarily not a priority making something a big red top
00:21:23.679 top big highest number one priority changes nothing but text styling if it were really important it would already be done period And I think that's that's
00:21:30.640 a really good thing to say um for every time that someone sat through and gone through the whole list of tickets and
00:21:37.039 carefully prioritized everyone something else will come up and you have to take that over anyway people will end up
00:21:43.440 gravitating towards the important stuff in doing them if it needs to be done first um so if you look at all this
00:21:50.240 stuff in any of your tools just try figuring out ways to get rid of it I think that's an important question you
00:21:55.440 got to ask yourself how we can keep simplifying our own development every single day um so like resist meta
00:22:02.559 work it's not actual work it makes you feel like the work you're doing is
00:22:07.600 actual work but you're just assigning priorities assigning labels the real work will get done
00:22:13.640 anyway so how do we use issues um these three ways something's broken hey
00:22:18.679 this is cool to-do list what do I mean by this uh this is one where Kevin said something's broken open an issue
00:22:26.080 fixed in like you know hour or two um um then we had stuff we're like hey wouldn't it be cool if and then we have
00:22:32.440 a discussion on whether or not that would actually be cool to be in GitHub some these have a really good tendency to turn into actual P requests and turn
00:22:39.400 into actual features but they're great way to get them down and uh you know get
00:22:45.039 a point of discussion and save them till later um also to-do list this is just sort of a short little thing we end up
00:22:50.760 doing at GitHub sometimes this is for the issues 2.0 launch and we just had a bulleted list of stuff that needed to be
00:22:55.799 done and then you just cross them off when they're done I mean it's simple but it's it's a very basic way to get stuff
00:23:02.279 done and you don't have to open up a whole new process track or anything like that um so I mean simple tools means
00:23:09.600 simpler products better products less time spending around with
00:23:15.279 priorities um I want to talk about OA a little
00:23:20.400 bit I love Ruby I really love Ruby it's so quick I'm not talking about
00:23:25.880 computationally because it is slow as dicks but otherwise it is so fast you can build
00:23:32.360 cool stuff all the time some of the stuff in my development folder I have something called Secretary of Labor it was in all caps I was really hammered
00:23:39.520 when I wrote it um I I still don't really know what it does it was a single Sinatra app and it had a a Sim Link in
00:23:47.520 it called what that link to itself um but I built it really quick um I have
00:23:54.960 one one called unmarked van which is a way to Stock People actual physical
00:24:00.120 locations um I have Trace which is a real-time status graphing in redus all of this stuff won't ship ever especially
00:24:07.799 not that first one but the point is it's really easy to build cool stuff just the
00:24:13.679 heck of building cool stuff and we're the same way inside of GitHub too we have like a crap ton of apps we have all
00:24:19.200 these individual apps which you know deal with you know CI from like business
00:24:24.600 related stuff to different ways of tracking campfire
00:24:30.080 Ridiculousness um but the idea is that we have all these sort of apps that help us out because it's fun to build it gets
00:24:35.159 people excited about working on stuff um it's it's a an outlet for if you get really bored on something you can build
00:24:40.640 a cool app but the problem is you have 30 apps or whatever the number actually was um and you don't want Outsiders to
00:24:47.159 see them I mean we're an open company but you know ideally you want something where it's more private um but you don't
00:24:53.840 want to have to build authentication into all of these different apps um so
00:24:58.880 for us it makes a lot of sense to use GitHub as authentication we already have all of our teams we have our organizations we have all of our users
00:25:05.200 into GitHub and we just use that and we use OA um to authenticate users um you
00:25:11.760 guys probably all seen this sort of popup on GitHub you know allow them to check out your profile um there's a
00:25:19.440 bunch of different stuff on uh GitHub that will let you do this sort of stuff one is a cooworker Corey donaho who says
00:25:26.120 or who made Sona off GitHub which is a quick easy Sinatra extension you can drop that in and then quickly check you
00:25:32.320 know does this logged in user have access to the GitHub organization if they do let them in and it's a quickly
00:25:37.919 way you don't have to make all of these separate apps figure out your
00:25:43.159 authentication because that will definitely break sooner rather than later um so I
00:25:49.880 mean security consistency chicity um it's cool to have all your stuff in one place this doesn't have to be a GitHub
00:25:56.320 thing um you can do the same thing with Twitter or anything that provides an ooth endpoint just get everyone's Twitter
00:26:01.880 names together and then use that as your authentication unless you want to use ldap or anything like that same sort of
00:26:08.000 purposes um this works for us because we're a small company we don't have to deal with a heavy authentication layer
00:26:13.880 behind our company um so don't reinvent the wheel um use it all in one place um
00:26:19.880 a lot simpler that way um I want to talk about hubot most get up talks now talk about hubot
00:26:26.720 because we love them that's our robot he sits on our campfire room he's really
00:26:33.840 creepy what can hubot do um he has something like 275 commands that he can
00:26:39.679 respond to um he can deploy every GitHub app he can run Branch level tests um he can do other stuff like play music in
00:26:45.880 the office um tell us who's in the office build usage graphs um send
00:26:51.520 receive text messages he he mustaches every images that's posted into chat
00:26:57.880 sort of like that um and there's just a whole bunch of stuff you can do like rank Twitter
00:27:03.799 followers and it's a very easy way to get everyone involved and build this cool thing that you use every single day
00:27:09.880 I mean it's no dejs um which means our designers don't have to learn Ruby necessarily to to to hack on them and
00:27:17.120 he's really cool um so I think Bots are really cool um you can use this same
00:27:22.480 thing it doesn't have to necessarily be at your campfire bot it can be some internal app and I think there's a lot of cool stuff you can do with that just
00:27:28.640 think about how you can automate your own process for example um one way you do it is to know the status of your
00:27:34.200 branch um we ask currently like you know what hasn't been deployed in hubal return with a compare view of like well
00:27:40.120 this stuff hasn't been deployed yet so you know pay attention to this stuff if you're going to make a deploy um this
00:27:46.200 also works for separate branches too like if we want to see what hasn't been deployed on this particular Branch this
00:27:51.640 all works because we know the Sha of the currently deployed state of the code um
00:27:56.720 and that all stems from just one endpoint github.com shaww and that will give us the Sha and this is really
00:28:02.240 helpful both in like hubot stuff it's helpful just in general to know what is actually out there running on the site
00:28:08.880 um there's also a lot of stuff you can do with the GitHub API that we use um we
00:28:14.320 have pull requests we can pipe in just ask them like what are the pull requests on a particular repo and we'll spit them
00:28:19.480 all out and then you can close them out or figure out what to do that day um we also have different stuff with uh issues
00:28:26.840 um we have sort of day every two weeks just to close out old stuff that's been lingering um so it's sort of fun to ask
00:28:33.240 it you know how much how many issues have we closed out today and he'll return back oh well it's 13 issues closed out today um and that's just a
00:28:40.120 sort of a good little Benchmark to help you feel motivated to close stuff out um
00:28:46.120 so ask yourself I mean what can you automate again doesn't have to be a campfire bot um you can automate just
00:28:51.399 really boring crap that you have to deal with every time every time you hire a new guy you have to set up all their user accounts you have to set up you
00:28:57.399 know the whole slew of stuff maybe you can run one script that just does it all um you know there's a bunch of different
00:29:03.360 API stuff with GitHub specifically that you can use um graphs I mean the the sky's the limit it's it's fun to get a
00:29:09.880 culture where people want to hack on stuff and automate stuff because automating stuff means that you you're
00:29:15.760 just saving everyone's time and saving everyone's freaking out about some new area that they don't have to that
00:29:22.080 they've never been exposed to um don't trust hubot he's really weird
00:29:28.960 um so I mean that that's the majority of what I had for you today um I think look
00:29:35.200 into how you can refine your own process to make things simpler can you make stuff better and simpler and make sure
00:29:41.640 that everybody knows what the hell you're talking about without actually adding all these layers to complexity I
00:29:47.600 think it's really important to try and figure out like constantly re-evaluate what are we doing wrong what
00:29:53.600 are we doing better because that this is the stuff that will kill you slowly over time if you end up um with so many
00:30:01.480 complex processes and you have to figure out how are we actually getting to where we want to get by the time you ask that
00:30:08.679 question it's already too late um so thanks I'm Zach the my slides will be up
Zach Holman
@holman
Explore all talks recorded at RubyConf 2011
+55