1 00:00:00,000 --> 00:00:03,500 [MUSIC PLAYING] 2 00:00:03,500 --> 00:00:16,224 3 00:00:16,224 --> 00:00:17,140 BRIAN YU: Hi everyone. 4 00:00:17,140 --> 00:00:19,410 Welcome back to Web Programming with Python and JavaScript. 5 00:00:19,410 --> 00:00:22,170 Today we're joined by some special guests from GitHub and Travis, 6 00:00:22,170 --> 00:00:24,045 which you'll recall we've been using in order 7 00:00:24,045 --> 00:00:25,856 to do version control and CI and CD. 8 00:00:25,856 --> 00:00:28,980 And they'll be here today to continue those conversations about what we can 9 00:00:28,980 --> 00:00:31,290 use version control and CI and CD for. 10 00:00:31,290 --> 00:00:33,720 And so first up, we have John from GitHub 11 00:00:33,720 --> 00:00:37,140 who has joined us today to talk to us about how we can use GitHub in order 12 00:00:37,140 --> 00:00:38,890 to work on our web applications. 13 00:00:38,890 --> 00:00:42,030 JOHN BRITTON: I'm looking forward to spending some time with you, 14 00:00:42,030 --> 00:00:43,680 building some cool features. 15 00:00:43,680 --> 00:00:46,680 So just an overview of what we're going to do today, I'm 16 00:00:46,680 --> 00:00:50,970 going to walk through the development flow 17 00:00:50,970 --> 00:00:54,375 that we use at GitHub to work on web applications. 18 00:00:54,375 --> 00:00:56,500 So we're primarily a software as a service company. 19 00:00:56,500 --> 00:00:57,780 We build web apps. 20 00:00:57,780 --> 00:01:02,010 So I'm going to walk you through what a typical day would look like for me 21 00:01:02,010 --> 00:01:06,381 in working on some Ruby on Rails code for GitHub Classroom. 22 00:01:06,381 --> 00:01:08,130 So GitHub Classroom, as you probably know, 23 00:01:08,130 --> 00:01:10,200 is an application for teachers and for students 24 00:01:10,200 --> 00:01:13,330 to use GitHub for learning how to code. 25 00:01:13,330 --> 00:01:18,490 And I think you're using it in CS50 already, or in this course. 26 00:01:18,490 --> 00:01:20,470 So yeah, let's get started. 27 00:01:20,470 --> 00:01:23,130 The first thing that I'm going to do is just hop into GitHub 28 00:01:23,130 --> 00:01:24,990 and go to the repository. 29 00:01:24,990 --> 00:01:28,750 30 00:01:28,750 --> 00:01:30,810 This is the GitHub Classroom repository. 31 00:01:30,810 --> 00:01:34,140 So it's an open source code, Ruby on Rails app. 32 00:01:34,140 --> 00:01:36,600 You can see there's different stuff going on here. 33 00:01:36,600 --> 00:01:37,330 You can watch it. 34 00:01:37,330 --> 00:01:39,300 There's a bunch of stars. 35 00:01:39,300 --> 00:01:40,530 All the code is down here. 36 00:01:40,530 --> 00:01:42,330 And then you can check out the Read Me. 37 00:01:42,330 --> 00:01:45,314 If you're interested in developing, getting involved in open source, 38 00:01:45,314 --> 00:01:47,730 I chose this project because it is an open source project. 39 00:01:47,730 --> 00:01:49,480 I'm a maintainer on this project. 40 00:01:49,480 --> 00:01:52,750 And if you're interested, you can send a pull request, open issues, 41 00:01:52,750 --> 00:01:54,501 and I'll be able interact with you. 42 00:01:54,501 --> 00:01:56,250 Also, it's great because it's open source, 43 00:01:56,250 --> 00:01:59,680 I can easily use it as an example here. 44 00:01:59,680 --> 00:02:05,580 This code powers a website, GitHub Classroom, which, if we log out here, 45 00:02:05,580 --> 00:02:09,389 is just a tool for creating programming exercises 46 00:02:09,389 --> 00:02:15,480 and distributing them to students, or people in your course 47 00:02:15,480 --> 00:02:17,290 to do coding exercises on GitHub. 48 00:02:17,290 --> 00:02:19,290 So what we're going to do is we're going to walk 49 00:02:19,290 --> 00:02:23,750 through the process of developing a feature using Git, making a branch, 50 00:02:23,750 --> 00:02:27,420 running our unit tests, sharing with our peers, 51 00:02:27,420 --> 00:02:31,260 getting feedback via a pull request, deploying to production, 52 00:02:31,260 --> 00:02:35,790 and also doing something that we call feature flipping, which 53 00:02:35,790 --> 00:02:39,840 is an approach to bringing out features to a live production application 54 00:02:39,840 --> 00:02:44,410 and slowly rolling them out over time or to specific people. 55 00:02:44,410 --> 00:02:46,939 So the first thing that we need to do-- 56 00:02:46,939 --> 00:02:48,730 and you can kind of follow along with this. 57 00:02:48,730 --> 00:02:51,021 I'm probably going to move too fast for you to keep up, 58 00:02:51,021 --> 00:02:53,220 but I want this to be kind of a tutorial like what 59 00:02:53,220 --> 00:02:55,030 you could do on your own time. 60 00:02:55,030 --> 00:02:58,870 So the first thing to do here is in the top right-hand corner of the repository 61 00:02:58,870 --> 00:03:00,790 there's a Fork button. 62 00:03:00,790 --> 00:03:02,520 And if you go and click that, it will let 63 00:03:02,520 --> 00:03:06,210 you create a copy of the repository in your personal account. 64 00:03:06,210 --> 00:03:12,300 I've already done that, so if I go to my browser and just type in my username 65 00:03:12,300 --> 00:03:17,400 here, you'll see that I have a fork. 66 00:03:17,400 --> 00:03:20,890 It says forked from education classroom. 67 00:03:20,890 --> 00:03:24,420 So this is the public open source main repository. 68 00:03:24,420 --> 00:03:29,010 And I have a copy of this repository in my personal GitHub account. 69 00:03:29,010 --> 00:03:35,280 Then what you would do from there is go to this Clone button right here 70 00:03:35,280 --> 00:03:39,440 and click on that, and just grab the URL and hop over to your terminal. 71 00:03:39,440 --> 00:03:42,820 72 00:03:42,820 --> 00:03:47,850 In your terminal, you would do git clone and paste in that URL. 73 00:03:47,850 --> 00:03:52,260 So now you can get a copy of the repository on your local machine 74 00:03:52,260 --> 00:03:56,340 with all the code for the app so you can run it locally and get started. 75 00:03:56,340 --> 00:04:00,120 I've already cloned it, just for the speed of this demo. 76 00:04:00,120 --> 00:04:04,410 So if I move into my source repository location, 77 00:04:04,410 --> 00:04:06,160 we can go ahead and run git status. 78 00:04:06,160 --> 00:04:09,195 And you can see that I have the master branch, everything is working. 79 00:04:09,195 --> 00:04:11,070 And if you want to look at the files, there's 80 00:04:11,070 --> 00:04:13,110 all these files and gems and cool stuff in here. 81 00:04:13,110 --> 00:04:15,810 82 00:04:15,810 --> 00:04:19,860 We follow a pattern on our repositories of scripting everything. 83 00:04:19,860 --> 00:04:23,580 So we want it to be, for a new contributor coming to our project, 84 00:04:23,580 --> 00:04:25,170 really easy to set up. 85 00:04:25,170 --> 00:04:29,050 So within the project, there's actually this file in the Scripts directory. 86 00:04:29,050 --> 00:04:32,280 So in here, we've got script. 87 00:04:32,280 --> 00:04:37,886 And inside there, we have a file called bootstrap. 88 00:04:37,886 --> 00:04:40,260 You run that and it will just set up your entire machine. 89 00:04:40,260 --> 00:04:43,170 The only prerequisite for this app is to have Docker installed. 90 00:04:43,170 --> 00:04:45,836 So you install Docker on your machine, you run script bootstrap, 91 00:04:45,836 --> 00:04:48,690 and you should be off to the races to get this running locally. 92 00:04:48,690 --> 00:04:51,780 In my case, I'm just going to go ahead and run script server. 93 00:04:51,780 --> 00:04:56,190 So after you've set everything up, you launch the server. 94 00:04:56,190 --> 00:04:58,950 You can see Docker is booting up the different services 95 00:04:58,950 --> 00:05:00,540 and different containers. 96 00:05:00,540 --> 00:05:04,500 And then if things go well, we'll have a locally running version 97 00:05:04,500 --> 00:05:05,615 of the application. 98 00:05:05,615 --> 00:05:09,117 99 00:05:09,117 --> 00:05:09,950 Takes just a moment. 100 00:05:09,950 --> 00:05:13,530 101 00:05:13,530 --> 00:05:14,155 So there we go. 102 00:05:14,155 --> 00:05:14,910 It says it's done. 103 00:05:14,910 --> 00:05:18,010 It's starting the Docker services. 104 00:05:18,010 --> 00:05:19,840 Connection succeeded. 105 00:05:19,840 --> 00:05:22,110 And if we switch over to our browser-- 106 00:05:22,110 --> 00:05:26,470 I'll put this over here, put the browser over here-- 107 00:05:26,470 --> 00:05:35,560 we can do HTTP localhost 5000. 108 00:05:35,560 --> 00:05:38,900 Once that finishes loading up. 109 00:05:38,900 --> 00:05:43,640 You can see the different services running and putting out their output. 110 00:05:43,640 --> 00:05:47,082 And then the Rail server is running. 111 00:05:47,082 --> 00:05:47,790 Now it's loading. 112 00:05:47,790 --> 00:05:55,150 113 00:05:55,150 --> 00:05:55,980 Great. 114 00:05:55,980 --> 00:06:01,324 So we have a locally running copy of the application. 115 00:06:01,324 --> 00:06:02,740 Doesn't look like much right here. 116 00:06:02,740 --> 00:06:03,864 It's just the landing page. 117 00:06:03,864 --> 00:06:06,095 So we go ahead and sign in and just see how it works. 118 00:06:06,095 --> 00:06:08,970 You can see a lot of stuff happening in the background in my console, 119 00:06:08,970 --> 00:06:11,928 but basically what's happening is it's connecting to my GitHub account, 120 00:06:11,928 --> 00:06:15,810 and it's logging me in as my user on GitHub on this application. 121 00:06:15,810 --> 00:06:18,220 And it shows-- this is kind of what the teacher sees 122 00:06:18,220 --> 00:06:19,720 when they're using GitHub Classroom. 123 00:06:19,720 --> 00:06:21,660 It's kind of overview of all their classrooms. 124 00:06:21,660 --> 00:06:25,410 It shows them what students they have, what assignments they've created, 125 00:06:25,410 --> 00:06:27,210 who submitted what when. 126 00:06:27,210 --> 00:06:29,610 And we're just going to add a really simple feature. 127 00:06:29,610 --> 00:06:33,520 We're going to go ahead and add a link to Harvard CS50 in the navigation. 128 00:06:33,520 --> 00:06:35,520 So we're not going to do any actual programming. 129 00:06:35,520 --> 00:06:37,920 We're just going to add a little bit of HTML 130 00:06:37,920 --> 00:06:41,800 as a sample of how this process works. 131 00:06:41,800 --> 00:06:49,235 Now, once we dive into the code, we're going to use a feature branch 132 00:06:49,235 --> 00:06:50,110 development strategy. 133 00:06:50,110 --> 00:06:54,320 So at GitHub, and commonly on teams that work on software as a service web 134 00:06:54,320 --> 00:07:00,074 applications, it's very common to take your project, make a branch, 135 00:07:00,074 --> 00:07:03,240 do a little bit of development off to the side just on one specific feature, 136 00:07:03,240 --> 00:07:05,190 and then merge it back into master, where 137 00:07:05,190 --> 00:07:07,898 the master branch, the main line of development for your project, 138 00:07:07,898 --> 00:07:09,227 represents production. 139 00:07:09,227 --> 00:07:10,810 That's what we do on GitHub Classroom. 140 00:07:10,810 --> 00:07:12,782 The master branch is what's in production. 141 00:07:12,782 --> 00:07:15,990 We do a single feature branch, and we go off to the side and we do some work, 142 00:07:15,990 --> 00:07:17,640 and then we merge it back in and we deploy it right away. 143 00:07:17,640 --> 00:07:19,560 So this is the idea of continuous deployment. 144 00:07:19,560 --> 00:07:22,650 We can deploy GitHub.com hundreds of times a day. 145 00:07:22,650 --> 00:07:25,590 We use the same flow on GitHub.com, but I use this as the example 146 00:07:25,590 --> 00:07:26,631 because it's open source. 147 00:07:26,631 --> 00:07:29,610 148 00:07:29,610 --> 00:07:33,030 A different way of doing this is kind of release-based development. 149 00:07:33,030 --> 00:07:36,000 And I think this is really common in desktop applications 150 00:07:36,000 --> 00:07:38,850 or any kind of software that goes in a package and is shipped out. 151 00:07:38,850 --> 00:07:40,599 Something you might see, like version 1.0, 152 00:07:40,599 --> 00:07:43,420 version 2.0, version 3.0 of the software. 153 00:07:43,420 --> 00:07:45,180 And generally what happens in those cases 154 00:07:45,180 --> 00:07:47,430 is you have a main line of development. 155 00:07:47,430 --> 00:07:49,320 You branch off for a new release. 156 00:07:49,320 --> 00:07:51,360 And you'll say, this is the 1.0 branch. 157 00:07:51,360 --> 00:07:54,510 And your developers will be just putting lots of stuff into the 1.0 branch. 158 00:07:54,510 --> 00:07:58,500 And eventually, that 1.0 branch might get merged back into master. 159 00:07:58,500 --> 00:08:01,920 But in the meantime, there could be a 1.1 branch 160 00:08:01,920 --> 00:08:06,180 started so that you can simultaneously be working on the upcoming release, 161 00:08:06,180 --> 00:08:09,780 and like maybe one release down the road for six months later. 162 00:08:09,780 --> 00:08:14,194 But in our case, I'm going to focus just on this feature branch development mode 163 00:08:14,194 --> 00:08:16,110 where we just make one branch for each feature 164 00:08:16,110 --> 00:08:20,010 or one branch for each bug report, and we merge that in and just kind of keep 165 00:08:20,010 --> 00:08:20,970 going. 166 00:08:20,970 --> 00:08:24,330 So I'm going to open up another terminal, 167 00:08:24,330 --> 00:08:28,031 and you'll see that I have my repository clone down locally. 168 00:08:28,031 --> 00:08:30,030 On the right-hand side of my terminal, that just 169 00:08:30,030 --> 00:08:32,700 says what branch I'm on and the current status of my repository 170 00:08:32,700 --> 00:08:34,440 if I ran git status. 171 00:08:34,440 --> 00:08:39,299 So every time I do something, that will automatically update. 172 00:08:39,299 --> 00:08:42,720 And the first step here is to get onto another branch. 173 00:08:42,720 --> 00:08:45,900 We need to make a branch to work on the side. 174 00:08:45,900 --> 00:08:50,960 So we'll use the command git checkout -b. 175 00:08:50,960 --> 00:08:53,910 git checkout allows you to select a branch and make it active, 176 00:08:53,910 --> 00:08:57,820 and the -b flag lets you create the branch at the same time. 177 00:08:57,820 --> 00:09:00,790 So I'll just call this Harvard. 178 00:09:00,790 --> 00:09:01,746 I'll make the branch. 179 00:09:01,746 --> 00:09:03,870 You'll notice on the right-hand side, it's updated. 180 00:09:03,870 --> 00:09:06,119 I'm on the Harvard branch. 181 00:09:06,119 --> 00:09:08,910 The next thing that I'm going to do here is open up my text editor. 182 00:09:08,910 --> 00:09:11,730 183 00:09:11,730 --> 00:09:14,790 So I'm using Atom, which is GitHub's text editor. 184 00:09:14,790 --> 00:09:18,450 And I'm going to open up a file called header.html. 185 00:09:18,450 --> 00:09:22,950 So this is on every page of-- 186 00:09:22,950 --> 00:09:23,834 let's see here. 187 00:09:23,834 --> 00:09:26,250 On every page of the site, you'll see we have this header. 188 00:09:26,250 --> 00:09:29,137 And it has like a GitHub Education link, a link to our forums, 189 00:09:29,137 --> 00:09:31,470 a link to some video tutorials, different stuff up here. 190 00:09:31,470 --> 00:09:34,330 And all of this is contained in this file. 191 00:09:34,330 --> 00:09:36,380 So I'm going to make a change that. 192 00:09:36,380 --> 00:09:41,710 What I'm going to do is just copy this GitHub Education link, 193 00:09:41,710 --> 00:09:46,320 and I'm going to just paste another copy of it and save it and refresh. 194 00:09:46,320 --> 00:09:49,140 195 00:09:49,140 --> 00:09:51,870 And so now you see I have the link twice. 196 00:09:51,870 --> 00:09:55,110 We're editing the local development environment. 197 00:09:55,110 --> 00:09:59,430 I'm going to go ahead and call this Harvard, 198 00:09:59,430 --> 00:10:03,105 and then I'm going to link to Harvard.edu. 199 00:10:03,105 --> 00:10:06,120 Now obviously, this isn't a features that we really want in the app, 200 00:10:06,120 --> 00:10:10,470 but you can imagine that I'm making some new feature, like the ability to grade 201 00:10:10,470 --> 00:10:15,690 assignments, or the ability to invite people, or different kinds of things. 202 00:10:15,690 --> 00:10:19,470 The important part here is that we're doing some kind of development 203 00:10:19,470 --> 00:10:23,220 on the app in its branch on the side, and that we can discuss it and share it 204 00:10:23,220 --> 00:10:26,460 with people on GitHub. 205 00:10:26,460 --> 00:10:28,150 So I go ahead and save that. 206 00:10:28,150 --> 00:10:30,858 And the next thing that I'm going to do is go back to my terminal 207 00:10:30,858 --> 00:10:33,140 and do git status. 208 00:10:33,140 --> 00:10:36,920 git status, I know you've covered some of Git in this course already, 209 00:10:36,920 --> 00:10:40,070 but git status, just as a refresher, tells you 210 00:10:40,070 --> 00:10:43,010 what's going on in your working directory and in your staging area, 211 00:10:43,010 --> 00:10:46,230 and what kind of the next thing you should do. 212 00:10:46,230 --> 00:10:47,480 So it gives you some pointers. 213 00:10:47,480 --> 00:10:51,740 It says, right here, use git add file to update what will be committed. 214 00:10:51,740 --> 00:10:54,170 So what we need to do here is we need to use git add, 215 00:10:54,170 --> 00:11:00,050 and then app views shared header partial dot html dot erb. 216 00:11:00,050 --> 00:11:03,950 So what this is saying is I want to put this file that I've 217 00:11:03,950 --> 00:11:05,750 modified into my staging area and prepare 218 00:11:05,750 --> 00:11:10,680 it to be committed as a new commit in my repository on the Harvard branch. 219 00:11:10,680 --> 00:11:12,680 So I do that. 220 00:11:12,680 --> 00:11:15,680 git status reports that it's modified. 221 00:11:15,680 --> 00:11:18,890 And then the last step here is to do git commit. 222 00:11:18,890 --> 00:11:20,880 When you commit, you include a message. 223 00:11:20,880 --> 00:11:24,690 And I'll say, add a link to Harvard. 224 00:11:24,690 --> 00:11:27,680 I should probably check and make sure that the link actually works. 225 00:11:27,680 --> 00:11:30,350 If I click it, it does, in fact, take us to Harvard. 226 00:11:30,350 --> 00:11:33,560 227 00:11:33,560 --> 00:11:38,570 All right, so now we've made our first commit on this new feature development 228 00:11:38,570 --> 00:11:39,530 that we're doing. 229 00:11:39,530 --> 00:11:43,757 And I want to show you a little bit about how to switch back and forth. 230 00:11:43,757 --> 00:11:45,590 So the first thing we did, we made a branch. 231 00:11:45,590 --> 00:11:46,798 We moved over to that branch. 232 00:11:46,798 --> 00:11:47,810 We made it active. 233 00:11:47,810 --> 00:11:52,160 We can, at the same time, use the command git checkout 234 00:11:52,160 --> 00:11:56,010 and specify a branch master to go back to our main line of development. 235 00:11:56,010 --> 00:11:59,960 This is the thing that's currently in production that everybody's using. 236 00:11:59,960 --> 00:12:03,110 I do that and I refresh this page, and you'll see that the link to Harvard 237 00:12:03,110 --> 00:12:04,310 disappeared. 238 00:12:04,310 --> 00:12:05,420 It's not on this branch. 239 00:12:05,420 --> 00:12:11,420 If I go git checkout Harvard and I refresh, it's now on this branch. 240 00:12:11,420 --> 00:12:14,340 And this is pretty accurate as to how I would be working normally. 241 00:12:14,340 --> 00:12:17,800 I would make a branch, do some stuff, run in development, see how it's going, 242 00:12:17,800 --> 00:12:19,850 and just keep checking things as I go until I get to the point 243 00:12:19,850 --> 00:12:21,500 where I'm like, yes, this is the thing I want. 244 00:12:21,500 --> 00:12:23,000 I want to push it out to production. 245 00:12:23,000 --> 00:12:24,380 It works. 246 00:12:24,380 --> 00:12:27,890 Now I need to get code review and run some unit tests to make sure 247 00:12:27,890 --> 00:12:30,770 that what I'm doing is right. 248 00:12:30,770 --> 00:12:34,100 So again, we started by forking the repository 249 00:12:34,100 --> 00:12:36,770 and we had it in our own account. 250 00:12:36,770 --> 00:12:39,572 And so what I'm going to do is I'm going to push it to my copy. 251 00:12:39,572 --> 00:12:42,030 I'm not going to push it to the main GitHub Education copy. 252 00:12:42,030 --> 00:12:43,680 I'm going to push it to my copy. 253 00:12:43,680 --> 00:12:48,680 So what I'll do is say git push johndbritton harvard. 254 00:12:48,680 --> 00:12:53,120 And in this case, johndbritton is the name of my remote 255 00:12:53,120 --> 00:12:56,690 that represents the repository, my fork of the repository. 256 00:12:56,690 --> 00:12:57,680 So it's here. 257 00:12:57,680 --> 00:12:59,900 It's this one. 258 00:12:59,900 --> 00:13:03,060 So that's what that means. 259 00:13:03,060 --> 00:13:05,066 So I'm going to push to that. 260 00:13:05,066 --> 00:13:07,190 And I'm going to push to the branch called Harvard. 261 00:13:07,190 --> 00:13:11,630 So this branch, I'm going to push it to a branch with the same name remotely. 262 00:13:11,630 --> 00:13:15,350 So you can see it pushes the code up to GitHub on my repository. 263 00:13:15,350 --> 00:13:19,310 And if I refresh the page on GitHub, you'll see that-- 264 00:13:19,310 --> 00:13:20,695 let's see here. 265 00:13:20,695 --> 00:13:22,700 If I go to the homepage. 266 00:13:22,700 --> 00:13:24,380 There you go. 267 00:13:24,380 --> 00:13:29,000 This yellow box says that less than a minute ago, I 268 00:13:29,000 --> 00:13:32,870 pushed a branch called Harvard to GitHub on my personal GitHub repository. 269 00:13:32,870 --> 00:13:35,870 And I can click this button here, Compare and Pull Request. 270 00:13:35,870 --> 00:13:38,240 So I'll do that. 271 00:13:38,240 --> 00:13:42,500 What a pull request does is it lets you start a conversation about some code, 272 00:13:42,500 --> 00:13:44,792 about some changes that you made. 273 00:13:44,792 --> 00:13:47,750 So in this case, I'm just going to say I want to add a link to Harvard. 274 00:13:47,750 --> 00:13:51,740 And up at the top, because this is a fork, 275 00:13:51,740 --> 00:13:57,950 you'll see it saying, I want to merge from my version of the repository 276 00:13:57,950 --> 00:14:01,340 on the Harvard branch to GitHub Education, the official version, 277 00:14:01,340 --> 00:14:02,330 on the master branch. 278 00:14:02,330 --> 00:14:06,930 I'm going to change this just to be my own version. 279 00:14:06,930 --> 00:14:10,190 So I'm going to merge my Harvard branch into my own version's master branch, 280 00:14:10,190 --> 00:14:13,800 just because I don't actually want to deploy this to our production instance. 281 00:14:13,800 --> 00:14:16,670 So I'm going to add a link to Harvard, like that, and just say, 282 00:14:16,670 --> 00:14:26,130 this is a simple example of a feature branch development 283 00:14:26,130 --> 00:14:30,050 for the Harvard course. 284 00:14:30,050 --> 00:14:33,680 And I can just say, create pull request. 285 00:14:33,680 --> 00:14:37,270 What happens is it automatically starts a build. 286 00:14:37,270 --> 00:14:42,440 So it goes off to Travis and it says, John made this branch. 287 00:14:42,440 --> 00:14:43,790 He made some new code. 288 00:14:43,790 --> 00:14:45,242 I want you to run all the tests. 289 00:14:45,242 --> 00:14:46,200 So what does that mean? 290 00:14:46,200 --> 00:14:47,158 Let's look at our test. 291 00:14:47,158 --> 00:14:50,420 While this is kind of doing some stuff in the background, 292 00:14:50,420 --> 00:14:53,930 I'm going to hop over to my editor. 293 00:14:53,930 --> 00:15:02,200 And if we go here and go to spec. 294 00:15:02,200 --> 00:15:03,500 So in here, we have-- 295 00:15:03,500 --> 00:15:05,510 let's zoom in. 296 00:15:05,510 --> 00:15:07,134 Within our repository of this folder-- 297 00:15:07,134 --> 00:15:08,300 So it's a Rails application. 298 00:15:08,300 --> 00:15:09,560 We're using RSpec. 299 00:15:09,560 --> 00:15:12,830 All of our specifications, all of our unit tests are within this one folder 300 00:15:12,830 --> 00:15:13,870 called spec. 301 00:15:13,870 --> 00:15:16,079 We have all these different kinds of specs. 302 00:15:16,079 --> 00:15:17,120 We have controller specs. 303 00:15:17,120 --> 00:15:18,320 We have helpers. 304 00:15:18,320 --> 00:15:20,580 We have background job specs. 305 00:15:20,580 --> 00:15:22,850 We have model specs, service specs. 306 00:15:22,850 --> 00:15:25,340 And each one of these things-- so if I say, for example, 307 00:15:25,340 --> 00:15:27,740 I'll go into my model specs. 308 00:15:27,740 --> 00:15:32,280 And I'll go in here and I'll check like the deadline specification. 309 00:15:32,280 --> 00:15:34,280 What this does is makes sure that when a teacher 310 00:15:34,280 --> 00:15:38,856 sets a deadline that we close down assignment submission on the deadline. 311 00:15:38,856 --> 00:15:40,980 And if somebody tries to submit, it gives an error. 312 00:15:40,980 --> 00:15:44,450 So there's all these different checks. 313 00:15:44,450 --> 00:15:46,480 In our case, our change was very minor. 314 00:15:46,480 --> 00:15:48,080 We just added a visual change. 315 00:15:48,080 --> 00:15:49,959 But we could have accidentally introduced 316 00:15:49,959 --> 00:15:51,500 some kind of bug, some kind of error. 317 00:15:51,500 --> 00:15:55,700 And so by running the tests, we're able to guarantee that nothing has changed, 318 00:15:55,700 --> 00:15:56,792 nothing has broken. 319 00:15:56,792 --> 00:15:59,000 Nothing important has broken anyways, because we have 320 00:15:59,000 --> 00:16:00,811 tests for everything that's important. 321 00:16:00,811 --> 00:16:02,810 So there's hundreds and hundreds of these tests. 322 00:16:02,810 --> 00:16:03,710 They're all running. 323 00:16:03,710 --> 00:16:12,740 And if I go in here and click on the Travis CI link, and I go to our build, 324 00:16:12,740 --> 00:16:14,970 it's building on different versions of Ruby. 325 00:16:14,970 --> 00:16:17,330 So I'll open up this one. 326 00:16:17,330 --> 00:16:20,330 And you can kind of see it's setting all of our environment variables, 327 00:16:20,330 --> 00:16:22,940 it's installing all kinds of-- 328 00:16:22,940 --> 00:16:26,630 all of our different-- oops. 329 00:16:26,630 --> 00:16:28,270 There we go. 330 00:16:28,270 --> 00:16:30,540 Yeah, what it actually says here-- we're not 331 00:16:30,540 --> 00:16:31,620 going to go through every one of these tests, obviously. 332 00:16:31,620 --> 00:16:33,470 But it's running all the tests. 333 00:16:33,470 --> 00:16:36,230 And then you can see as they run that they're passing. 334 00:16:36,230 --> 00:16:37,440 It's kind of live updating. 335 00:16:37,440 --> 00:16:40,140 So this takes a couple of minutes. 336 00:16:40,140 --> 00:16:45,330 Once that's done, I'll get a green status update on my repository 337 00:16:45,330 --> 00:16:48,660 on the pull request saying that, yes, in fact, this did pass all the tests, 338 00:16:48,660 --> 00:16:51,990 so you should feel very confident about deploying this to production. 339 00:16:51,990 --> 00:16:57,360 In the meantime, what would commonly happen is my coworkers would come in, 340 00:16:57,360 --> 00:16:59,340 or other people on the open source project 341 00:16:59,340 --> 00:17:01,590 would come in and review the changes. 342 00:17:01,590 --> 00:17:04,710 In our case, the change is rather trivial, so I'll just come in here 343 00:17:04,710 --> 00:17:08,310 and just say, this looks great. 344 00:17:08,310 --> 00:17:10,647 And I will zoom in on that. 345 00:17:10,647 --> 00:17:18,510 This looks great, let's ship it. 346 00:17:18,510 --> 00:17:20,859 Add a comment. 347 00:17:20,859 --> 00:17:23,200 And so we can collaborate on that. 348 00:17:23,200 --> 00:17:24,950 What would be pretty common to see here is 349 00:17:24,950 --> 00:17:27,960 say you did something that might be a security concern. 350 00:17:27,960 --> 00:17:30,810 Somebody from your security team could come in and give comments 351 00:17:30,810 --> 00:17:35,310 about what you need to check, make sure that you're following best practices, 352 00:17:35,310 --> 00:17:38,850 kind of give you a second set of eyes so that you end up in a position 353 00:17:38,850 --> 00:17:42,420 where you're writing the best code you can. 354 00:17:42,420 --> 00:17:48,165 It's going to take a couple of minutes for this to run, so I want to jump to-- 355 00:17:48,165 --> 00:17:50,770 356 00:17:50,770 --> 00:17:54,070 jump back to the code. 357 00:17:54,070 --> 00:17:55,980 So we're going to cover a few things. 358 00:17:55,980 --> 00:17:57,350 We did branches. 359 00:17:57,350 --> 00:17:59,040 We made a pull request. 360 00:17:59,040 --> 00:18:00,750 We're doing automated build. 361 00:18:00,750 --> 00:18:02,620 We got some review. 362 00:18:02,620 --> 00:18:05,250 And then we're going to talk about deploying. 363 00:18:05,250 --> 00:18:10,320 So every setup is different, how you're going to deploy your project. 364 00:18:10,320 --> 00:18:12,990 In our case, we use our chat tool. 365 00:18:12,990 --> 00:18:15,870 So we have a shared chat, kind of chat room thing. 366 00:18:15,870 --> 00:18:22,280 And every time we make a change, those changes get propagated to our chat tool 367 00:18:22,280 --> 00:18:23,710 as kind of a notification. 368 00:18:23,710 --> 00:18:26,457 And then we can run a command in our chat client that says-- 369 00:18:26,457 --> 00:18:27,040 we have a bot. 370 00:18:27,040 --> 00:18:28,200 His name's Hubot. 371 00:18:28,200 --> 00:18:32,170 And we tell Hubot, Hubot, go deploy GitHub Classroom to production. 372 00:18:32,170 --> 00:18:34,594 And we can even specify, go deploy this branch 373 00:18:34,594 --> 00:18:36,010 of GitHub Classroom to production. 374 00:18:36,010 --> 00:18:38,310 So I could say, for example-- 375 00:18:38,310 --> 00:18:41,530 376 00:18:41,530 --> 00:18:47,400 where is my-- here we go. 377 00:18:47,400 --> 00:18:49,930 So for example, in here I could say, for example, 378 00:18:49,930 --> 00:18:55,560 deploy classroom/harvard to production. 379 00:18:55,560 --> 00:18:57,769 I'm not going to run this right now, but essentially, 380 00:18:57,769 --> 00:18:59,643 if I wanted to deploy this out to production, 381 00:18:59,643 --> 00:19:01,000 that's exactly what I would do. 382 00:19:01,000 --> 00:19:05,700 And as you can see from before, I deployed classroom, the master branch. 383 00:19:05,700 --> 00:19:08,040 Hubot replied to me that I was deploying. 384 00:19:08,040 --> 00:19:10,500 I got a success option. 385 00:19:10,500 --> 00:19:13,960 And then it said it was finished. 386 00:19:13,960 --> 00:19:16,200 Let's check in on Travis. 387 00:19:16,200 --> 00:19:20,550 OK, our build-- wait, this is not the right one. 388 00:19:20,550 --> 00:19:23,050 We had one build fail and one build pass. 389 00:19:23,050 --> 00:19:24,230 I don't know why we failed. 390 00:19:24,230 --> 00:19:35,520 391 00:19:35,520 --> 00:19:37,180 This one will restart. 392 00:19:37,180 --> 00:19:41,040 All right, so anyway, we go back to-- 393 00:19:41,040 --> 00:19:42,450 where did our thing go? 394 00:19:42,450 --> 00:19:45,020 395 00:19:45,020 --> 00:19:46,520 Oh, I have to press the back button. 396 00:19:46,520 --> 00:19:48,630 I lost my tab. 397 00:19:48,630 --> 00:19:51,504 So if we go back here, anyway, this pull request build passed, 398 00:19:51,504 --> 00:19:52,670 so let's check that one out. 399 00:19:52,670 --> 00:19:55,540 400 00:19:55,540 --> 00:19:59,650 So ultimately, we ran all of the tests. 401 00:19:59,650 --> 00:20:01,240 We've seen them all passing here. 402 00:20:01,240 --> 00:20:03,040 So I feel pretty confident that the change 403 00:20:03,040 --> 00:20:08,627 I made by adding a link to the navigation, I didn't break anything. 404 00:20:08,627 --> 00:20:11,210 So I could go ahead and merge this in, into the master branch, 405 00:20:11,210 --> 00:20:12,550 and be totally happy. 406 00:20:12,550 --> 00:20:20,769 However, this is a common path to take when you're doing smaller features. 407 00:20:20,769 --> 00:20:21,310 You build it. 408 00:20:21,310 --> 00:20:21,820 You test it. 409 00:20:21,820 --> 00:20:22,450 You make sure it works. 410 00:20:22,450 --> 00:20:23,090 You get code review. 411 00:20:23,090 --> 00:20:23,980 You put it out there. 412 00:20:23,980 --> 00:20:27,100 But what happens when you're doing like a really big feature? 413 00:20:27,100 --> 00:20:30,010 If you're doing release-based development, 414 00:20:30,010 --> 00:20:33,550 you might lump all of those changes together into one big release and say, 415 00:20:33,550 --> 00:20:36,190 this is the new release that supports this new thing. 416 00:20:36,190 --> 00:20:39,100 But when you're doing continuous deployment with a web application, 417 00:20:39,100 --> 00:20:42,100 you can't really do that. 418 00:20:42,100 --> 00:20:45,460 Diverging from the production version is your enemy. 419 00:20:45,460 --> 00:20:48,820 The longer you have a branch open where you're making changes, making changes, 420 00:20:48,820 --> 00:20:50,890 making changes, and not re-integrating that back 421 00:20:50,890 --> 00:20:53,020 to the main line of development, the harder you're 422 00:20:53,020 --> 00:20:54,550 making your life for the future. 423 00:20:54,550 --> 00:20:58,940 So what we like to do is use feature toggles. 424 00:20:58,940 --> 00:21:03,910 So we'll create kind of a break, a logical break 425 00:21:03,910 --> 00:21:08,620 in the code, where you can choose two code paths based on certain variables. 426 00:21:08,620 --> 00:21:12,670 And that allows us to deploy new features to the public production 427 00:21:12,670 --> 00:21:16,630 version of our website or our app without impacting all of our users 428 00:21:16,630 --> 00:21:17,500 immediately. 429 00:21:17,500 --> 00:21:19,592 So practically speaking, what does this mean? 430 00:21:19,592 --> 00:21:22,300 This means that I want to be able to deploy this new feature that 431 00:21:22,300 --> 00:21:26,840 links to Harvard to production, but I want it to be disabled by default. 432 00:21:26,840 --> 00:21:28,090 So I want nobody to see it. 433 00:21:28,090 --> 00:21:30,040 I just want that code to be in production and ready to go 434 00:21:30,040 --> 00:21:31,051 whenever I need it. 435 00:21:31,051 --> 00:21:33,550 And I want to be able to enable it for one person at a time. 436 00:21:33,550 --> 00:21:37,100 So I want to be able say, when John accesses his web page, 437 00:21:37,100 --> 00:21:40,719 then it should show the Harvard link. 438 00:21:40,719 --> 00:21:42,760 But when anybody else accesses it, it should not. 439 00:21:42,760 --> 00:21:44,510 So that's called a feature toggle, and I'm 440 00:21:44,510 --> 00:21:48,520 going to show you how we build those and deploy them into production. 441 00:21:48,520 --> 00:21:52,810 So I'll go back to my header. 442 00:21:52,810 --> 00:21:55,580 And it's pretty straightforward. 443 00:21:55,580 --> 00:21:58,827 We have one line here, this line number 7, which links out to Harvard. 444 00:21:58,827 --> 00:22:00,910 What we want to do is add a conditional around it. 445 00:22:00,910 --> 00:22:03,370 The conditional should be based off of the current user, 446 00:22:03,370 --> 00:22:06,370 and it should be based off of if the Harvard feature is enabled or not 447 00:22:06,370 --> 00:22:08,022 enabled. 448 00:22:08,022 --> 00:22:09,730 So the first thing I'm going to do is I'm 449 00:22:09,730 --> 00:22:13,090 going to use some Ruby syntax to say, I'm writing logic code. 450 00:22:13,090 --> 00:22:19,010 And I will say, if current_user.feature_enabled question 451 00:22:19,010 --> 00:22:22,940 mark, and then I'll call the feature Harvard. 452 00:22:22,940 --> 00:22:24,800 Simple IF statement. 453 00:22:24,800 --> 00:22:29,020 If the feature's enabled, I want to link to Harvard. 454 00:22:29,020 --> 00:22:30,980 And that's it. 455 00:22:30,980 --> 00:22:32,882 And then I just say end to end the statement. 456 00:22:32,882 --> 00:22:34,590 If the feature's not enabled, do nothing. 457 00:22:34,590 --> 00:22:37,600 458 00:22:37,600 --> 00:22:39,150 OK, so I'll save that. 459 00:22:39,150 --> 00:22:43,717 Now if I go back to my browser and go to my local copy, 460 00:22:43,717 --> 00:22:45,925 you can tell that this is my local copy, because it's 461 00:22:45,925 --> 00:22:50,180 got this red bar across the top, which is kind of development mode for us. 462 00:22:50,180 --> 00:22:52,220 And you can see the Harvard link is here. 463 00:22:52,220 --> 00:22:56,630 If I refresh this page, it's gone, OK? 464 00:22:56,630 --> 00:23:01,370 That's because the feature is not enabled. 465 00:23:01,370 --> 00:23:05,900 Up here in the top, there's this Site Admin button. 466 00:23:05,900 --> 00:23:09,920 This links into a backend for developers who work on this app. 467 00:23:09,920 --> 00:23:12,920 So if you're a developer working on the open source version of this app, 468 00:23:12,920 --> 00:23:16,520 you would have access to this through your copy of the app. 469 00:23:16,520 --> 00:23:20,210 Or if you were a GitHub staff employee working on the production version, 470 00:23:20,210 --> 00:23:23,420 you'd be able to access this as well. 471 00:23:23,420 --> 00:23:27,770 Within this interface, we link out to this thing called Features. 472 00:23:27,770 --> 00:23:33,260 And Features, this tool, is actually an open source Ruby gem called Flipper. 473 00:23:33,260 --> 00:23:34,805 So it's GitHub Flipper. 474 00:23:34,805 --> 00:23:37,850 475 00:23:37,850 --> 00:23:39,354 So here's the gem. 476 00:23:39,354 --> 00:23:42,020 If you're interested in building apps that have feature flippers 477 00:23:42,020 --> 00:23:45,590 and you're using Rails, this is definitely a thing to check out. 478 00:23:45,590 --> 00:23:49,190 It's probably too in-depth for me to go into all of how this works, 479 00:23:49,190 --> 00:23:55,934 but we didn't build everything that I'm showing you uniquely for this app. 480 00:23:55,934 --> 00:23:58,850 Every Rails app that we use has the ability to do this feature flipper 481 00:23:58,850 --> 00:24:00,531 thing through a third party library. 482 00:24:00,531 --> 00:24:02,780 In JavaScript, there are other libraries that do this. 483 00:24:02,780 --> 00:24:05,655 Different frameworks have different libraries for this kind of thing. 484 00:24:05,655 --> 00:24:10,620 So it's a common pattern in deploying production web applications. 485 00:24:10,620 --> 00:24:11,870 And also desktop applications. 486 00:24:11,870 --> 00:24:14,580 We do this in some of our desktop apps as well. 487 00:24:14,580 --> 00:24:16,514 So anyway, I'll click on the Features toggle. 488 00:24:16,514 --> 00:24:17,930 And it says there are no features. 489 00:24:17,930 --> 00:24:19,190 You need to add a feature. 490 00:24:19,190 --> 00:24:21,230 So I'll go in here and click Add Feature, 491 00:24:21,230 --> 00:24:26,210 and I'll call it Harvard right here. 492 00:24:26,210 --> 00:24:27,990 And then click Add Feature. 493 00:24:27,990 --> 00:24:32,180 And now I have this nice interface that shows me ways to enable the feature. 494 00:24:32,180 --> 00:24:34,700 I can enable the feature for a percentage of actors. 495 00:24:34,700 --> 00:24:40,340 That means if you have 100 users, enable it for 1 in every 100, 496 00:24:40,340 --> 00:24:41,569 2 out of every 100. 497 00:24:41,569 --> 00:24:43,610 What's interesting about the percentage of actors 498 00:24:43,610 --> 00:24:48,056 is that that is based off of the fact that when 499 00:24:48,056 --> 00:24:50,930 a feature is enabled for a given user, it stays enabled for that user 500 00:24:50,930 --> 00:24:51,800 all the time. 501 00:24:51,800 --> 00:24:54,800 It's very important that if somebody goes your website and the feature's 502 00:24:54,800 --> 00:24:58,190 enabled on one page and they navigate to the next page, it shouldn't disappear. 503 00:24:58,190 --> 00:25:02,240 So you can think about this as taking a numerical ID for the user 504 00:25:02,240 --> 00:25:04,610 and doing like mod something. 505 00:25:04,610 --> 00:25:07,800 And if it has a remainder or not, it's enabled. 506 00:25:07,800 --> 00:25:11,300 So for a given user, it will always be enabled or not be enabled. 507 00:25:11,300 --> 00:25:13,650 The other option is percentage of time. 508 00:25:13,650 --> 00:25:16,490 This allows the feature to be enabled, basically, 509 00:25:16,490 --> 00:25:18,524 for every request, 1 request out of 100. 510 00:25:18,524 --> 00:25:20,690 So for the same user, it might be enabled sometimes. 511 00:25:20,690 --> 00:25:21,800 It might not be. 512 00:25:21,800 --> 00:25:23,990 It just depends on what you're implementing. 513 00:25:23,990 --> 00:25:27,670 And then lastly, there's individual groups and individual actors. 514 00:25:27,670 --> 00:25:31,160 So I can enable a feature just for one user or just for one group. 515 00:25:31,160 --> 00:25:34,640 Since this is my development environment, I know my user ID is 1. 516 00:25:34,640 --> 00:25:37,996 So I'm just going to table this for user 1. 517 00:25:37,996 --> 00:25:40,130 I'll just enter this in here. 518 00:25:40,130 --> 00:25:43,520 Click Add Actor, and now the feature is partially enabled. 519 00:25:43,520 --> 00:25:45,300 You can see it's yellow. 520 00:25:45,300 --> 00:25:48,530 And if I switch back-- 521 00:25:48,530 --> 00:25:50,810 where did my thing go? 522 00:25:50,810 --> 00:25:52,400 Oh, I have to go back here. 523 00:25:52,400 --> 00:25:56,430 If I switch back to my local host and load the page, 524 00:25:56,430 --> 00:25:59,060 you'll see that now the Harvard link is here. 525 00:25:59,060 --> 00:26:02,900 Now, I'll open up a separate window, incognito window, 526 00:26:02,900 --> 00:26:07,760 and I'll go localhost 5000. 527 00:26:07,760 --> 00:26:09,560 And this time I log in as a different user. 528 00:26:09,560 --> 00:26:11,680 Uh-oh, what'd I do? 529 00:26:11,680 --> 00:26:13,420 Oh, it was disable this feature. 530 00:26:13,420 --> 00:26:23,840 531 00:26:23,840 --> 00:26:24,560 Let's do this. 532 00:26:24,560 --> 00:26:34,100 533 00:26:34,100 --> 00:26:35,860 I'll log in as a different user. 534 00:26:35,860 --> 00:26:38,620 535 00:26:38,620 --> 00:26:43,160 And then in this case, I just have a student, like a test account. 536 00:26:43,160 --> 00:26:44,577 I'll authorize this. 537 00:26:44,577 --> 00:26:46,660 So now I'm logged in in this browser window, which 538 00:26:46,660 --> 00:26:49,690 has the gray bar, as a different user. 539 00:26:49,690 --> 00:26:52,910 Go back to my code and fix that. 540 00:26:52,910 --> 00:26:57,070 And for this user, you'll notice that the Harvard link is not enabled. 541 00:26:57,070 --> 00:27:00,596 But for this user, the Harvard link is enabled. 542 00:27:00,596 --> 00:27:02,470 So I basically have a feature toggle in there 543 00:27:02,470 --> 00:27:06,580 that allows me to specifically say which users get what. 544 00:27:06,580 --> 00:27:08,480 Why is this useful? 545 00:27:08,480 --> 00:27:11,650 This can be very useful if you do-- 546 00:27:11,650 --> 00:27:14,700 when you're making new features, you can enable it just for your friends, 547 00:27:14,700 --> 00:27:17,283 or you can enable it just for people who work at your company, 548 00:27:17,283 --> 00:27:19,317 or you can enable it just for beta testers. 549 00:27:19,317 --> 00:27:21,025 So what this means is like the problem we 550 00:27:21,025 --> 00:27:23,200 were trying to solve before is that you can diverge 551 00:27:23,200 --> 00:27:26,200 from your main line of development, and the longer you stay diverging 552 00:27:26,200 --> 00:27:29,530 and you keep spreading apart, the harder it is to reintegrate your code later. 553 00:27:29,530 --> 00:27:32,080 This means that you can add a feature toggle, 554 00:27:32,080 --> 00:27:35,530 put in an unfinished feature, or a beta feature, 555 00:27:35,530 --> 00:27:39,190 merge it in, and every time you improve it, just make a new pull request, 556 00:27:39,190 --> 00:27:42,370 a new branch, doing it bit by bit by bit, and you're always re-integrated. 557 00:27:42,370 --> 00:27:44,740 So you never have this big scary day where you say, 558 00:27:44,740 --> 00:27:46,900 we made this huge new feature for the app. 559 00:27:46,900 --> 00:27:48,340 Now we have to integrate it with all the other work 560 00:27:48,340 --> 00:27:49,690 all the other developers have been doing. 561 00:27:49,690 --> 00:27:52,273 It's been integrated all along, so now you just click a button 562 00:27:52,273 --> 00:27:53,530 and it's enabled. 563 00:27:53,530 --> 00:27:56,696 Then once you're happy with the feature and you know it's been working well, 564 00:27:56,696 --> 00:27:59,110 you can delete the code that lets you choose two paths 565 00:27:59,110 --> 00:28:02,660 and let it just have one path. 566 00:28:02,660 --> 00:28:10,450 So if we go back to our feature toggle board and click on Harvard, 567 00:28:10,450 --> 00:28:12,010 I'll disable it for my user. 568 00:28:12,010 --> 00:28:17,390 And instead, I will enable it 50% of the time. 569 00:28:17,390 --> 00:28:21,760 So if I go to my private user and I refresh, 570 00:28:21,760 --> 00:28:23,810 it's not there the first request. 571 00:28:23,810 --> 00:28:25,360 Not there the second request. 572 00:28:25,360 --> 00:28:26,850 Oh, there it is. 573 00:28:26,850 --> 00:28:29,050 Now you see it showed up right here. 574 00:28:29,050 --> 00:28:32,574 If I refresh it again it might disappear. 575 00:28:32,574 --> 00:28:33,490 Eventually comes back. 576 00:28:33,490 --> 00:28:34,780 So 50% of the requests. 577 00:28:34,780 --> 00:28:36,310 And that's true across all users. 578 00:28:36,310 --> 00:28:41,330 So if I go to my normal account, it would do that as well. 579 00:28:41,330 --> 00:28:43,000 Put it to zero. 580 00:28:43,000 --> 00:28:45,526 And then ultimately, you can just click Enable here 581 00:28:45,526 --> 00:28:46,900 and it will enable for everybody. 582 00:28:46,900 --> 00:28:49,450 All the time, enabled for everyone. 583 00:28:49,450 --> 00:28:54,280 So now we're able to create a feature flag, push it out to production, 584 00:28:54,280 --> 00:28:57,470 and see it in action. 585 00:28:57,470 --> 00:29:00,460 So here we go. 586 00:29:00,460 --> 00:29:04,690 In my case, what I want to do is look at the code. 587 00:29:04,690 --> 00:29:06,820 We're happy with this feature toggle. 588 00:29:06,820 --> 00:29:10,120 Then we say git status. 589 00:29:10,120 --> 00:29:17,480 We have modified this file with a git add app views shared header. 590 00:29:17,480 --> 00:29:27,110 And then git commit, which says enable harvard feature behind a feature flag. 591 00:29:27,110 --> 00:29:31,620 All right, and lastly, I'll say get push johndbritton harvard. 592 00:29:31,620 --> 00:29:35,860 So this will push it up to my forked copy of the repository. 593 00:29:35,860 --> 00:29:37,900 And that will run the builds again. 594 00:29:37,900 --> 00:29:40,234 It'll run all the unit tests again, make sure it's good. 595 00:29:40,234 --> 00:29:42,150 Now, I'm also going to go ahead and push this. 596 00:29:42,150 --> 00:29:45,440 I'm not going to create a pull request for this on the main public project, 597 00:29:45,440 --> 00:29:48,440 but I do want to show you how deploying works. 598 00:29:48,440 --> 00:29:51,460 So what I'm going to do is I'm going to say git-- 599 00:29:51,460 --> 00:29:53,680 I want to do this in here. 600 00:29:53,680 --> 00:29:55,960 I need to add one more thing. 601 00:29:55,960 --> 00:30:01,840 If current user and. 602 00:30:01,840 --> 00:30:05,527 So I need this line, because you saw the error I got before. 603 00:30:05,527 --> 00:30:07,610 Because I was logged out, I wasn't a current user, 604 00:30:07,610 --> 00:30:08,920 so I caused the app to crash. 605 00:30:08,920 --> 00:30:10,540 I don't want to cause our production app to crash, 606 00:30:10,540 --> 00:30:13,750 so I'm going to add this if current user and if the feature is enabled, 607 00:30:13,750 --> 00:30:15,114 then do this thing. 608 00:30:15,114 --> 00:30:17,530 Otherwise, if there's nobody logged in, don't do anything, 609 00:30:17,530 --> 00:30:20,560 or if the feature's not enabled, don't do anything. 610 00:30:20,560 --> 00:30:25,800 So git add-- what's it called? 611 00:30:25,800 --> 00:30:30,640 git status, git add app views shared header, 612 00:30:30,640 --> 00:30:39,460 git commit -m, check for current user, git push harvard. 613 00:30:39,460 --> 00:30:42,715 And I'm also going to git push origin harvard. 614 00:30:42,715 --> 00:30:45,740 615 00:30:45,740 --> 00:30:48,650 So in this case, I'm actually going to push the change up 616 00:30:48,650 --> 00:30:53,540 to the real production application's repository. 617 00:30:53,540 --> 00:30:58,506 And then what will happen is if I go in here, you'll see in my chat-- 618 00:30:58,506 --> 00:31:01,130 so this is really important to the way GitHub works and the way 619 00:31:01,130 --> 00:31:02,386 we work with teams. 620 00:31:02,386 --> 00:31:05,510 You can see I created the branch and I got a notification in the chat room. 621 00:31:05,510 --> 00:31:09,290 All of the other people on my team also got this notification. 622 00:31:09,290 --> 00:31:11,360 And they'll see it in the chat room. 623 00:31:11,360 --> 00:31:14,309 What's interesting is like I'm doing all this work on my command line. 624 00:31:14,309 --> 00:31:16,850 You can all watch and you can see because I'm screen sharing. 625 00:31:16,850 --> 00:31:20,210 But my coworkers can't see any of the commands I'm running. 626 00:31:20,210 --> 00:31:23,240 The reason we have all of this stuff publish out to our chat channel 627 00:31:23,240 --> 00:31:26,610 is because it gives visibility into what commands 628 00:31:26,610 --> 00:31:28,560 we're running to the entire group. 629 00:31:28,560 --> 00:31:31,100 So by using Hubot and using a chat tool, we're 630 00:31:31,100 --> 00:31:35,720 able to have a shared command line where people can see what's 631 00:31:35,720 --> 00:31:38,210 happening in the deployment process. 632 00:31:38,210 --> 00:31:41,880 633 00:31:41,880 --> 00:31:49,030 So in our chat tool, I can run CI build classroom harvard. 634 00:31:49,030 --> 00:31:53,932 And what that's going to do is it's going to say, go to my CI tool. 635 00:31:53,932 --> 00:31:54,432 Uh-oh. 636 00:31:54,432 --> 00:32:00,650 637 00:32:00,650 --> 00:32:01,570 That's not good. 638 00:32:01,570 --> 00:32:04,870 Well, it runs automatically as well. 639 00:32:04,870 --> 00:32:10,180 GitHub.com education classroom. 640 00:32:10,180 --> 00:32:13,460 If I go here, now you'll notice this is not 641 00:32:13,460 --> 00:32:15,850 the forked version of the repository. 642 00:32:15,850 --> 00:32:17,950 This is the actual version of the repository. 643 00:32:17,950 --> 00:32:22,030 I can go to this branch and I'll see the Harvard branch. 644 00:32:22,030 --> 00:32:25,720 And you can see the build is pending on Travis. 645 00:32:25,720 --> 00:32:28,270 So I can click this and see what's happening. 646 00:32:28,270 --> 00:32:32,320 Once this build finishes, I'll be able to actually deploy this out 647 00:32:32,320 --> 00:32:34,184 to production and try it out. 648 00:32:34,184 --> 00:32:37,080 649 00:32:37,080 --> 00:32:40,260 So while this is building, does anybody in the audience 650 00:32:40,260 --> 00:32:42,980 have any questions while we wait for this for a sec? 651 00:32:42,980 --> 00:32:46,660 652 00:32:46,660 --> 00:32:47,779 Yes, in the back. 653 00:32:47,779 --> 00:32:51,691 AUDIENCE: When you said your command line was pushed out to the chat, 654 00:32:51,691 --> 00:32:54,529 I didn't see what you meant by the command line, what-- 655 00:32:54,529 --> 00:32:57,070 JOHN BRITTON: Yeah, so the question was about my command line 656 00:32:57,070 --> 00:32:58,300 being in the chat tool. 657 00:32:58,300 --> 00:33:00,800 It's actually not that the command line is in the chat tool, 658 00:33:00,800 --> 00:33:04,885 but what I wanted to show is that while I was working on my command line, 659 00:33:04,885 --> 00:33:06,760 all my git commands, they were private to me. 660 00:33:06,760 --> 00:33:07,970 Nobody could see them. 661 00:33:07,970 --> 00:33:11,140 But when it comes to deploying a product, deploying a service, 662 00:33:11,140 --> 00:33:14,650 it's important for the team to be in communication and know what's going on. 663 00:33:14,650 --> 00:33:16,733 So we don't actually deploy from our command line. 664 00:33:16,733 --> 00:33:17,710 We deploy from chat. 665 00:33:17,710 --> 00:33:20,431 So I'm about to demonstrate that as soon as the build's finished, 666 00:33:20,431 --> 00:33:22,180 but I'll be able to go into our chat room. 667 00:33:22,180 --> 00:33:25,750 Actually, I could do it with the master branch while this builds. 668 00:33:25,750 --> 00:33:30,810 So I can go to our chat tool and I can say-- 669 00:33:30,810 --> 00:33:32,620 OK, you can see the build was successful. 670 00:33:32,620 --> 00:33:38,170 But I can say, for example, deploy classroom/master. 671 00:33:38,170 --> 00:33:41,770 So I'm going to deploy the master branch of my app to production. 672 00:33:41,770 --> 00:33:44,110 And so now when I do this, everybody on my team 673 00:33:44,110 --> 00:33:46,660 can see that I'm currently doing deployment. 674 00:33:46,660 --> 00:33:48,400 Nobody else can deploy. 675 00:33:48,400 --> 00:33:53,047 The deploy queue is locked, and you can see that my deployment is done. 676 00:33:53,047 --> 00:33:54,130 It went out to production. 677 00:33:54,130 --> 00:33:57,440 I literally just deployed the app to production as we were talking. 678 00:33:57,440 --> 00:34:00,420 But everybody else on the team can see that I'm doing this. 679 00:34:00,420 --> 00:34:01,761 Does that answer your question? 680 00:34:01,761 --> 00:34:02,683 AUDIENCE: Yes. 681 00:34:02,683 --> 00:34:06,380 And how would you set up-- were those hooks that were set up? 682 00:34:06,380 --> 00:34:08,800 JOHN BRITTON: Yeah, so this is all set up via Hubot. 683 00:34:08,800 --> 00:34:12,372 So it's an open source tool you could use to kind of set up your own thing. 684 00:34:12,372 --> 00:34:14,080 There's also this thing called the GitHub 685 00:34:14,080 --> 00:34:17,440 app, which it's a Slack integration. 686 00:34:17,440 --> 00:34:19,960 You could enable this for your Slack, which 687 00:34:19,960 --> 00:34:24,110 is giving us all these notifications. 688 00:34:24,110 --> 00:34:32,989 All right, so now we can see right here it says, Travis CI build successful, 689 00:34:32,989 --> 00:34:34,921 education/classroom - ref harvard. 690 00:34:34,921 --> 00:34:36,170 So this is the branch that I-- 691 00:34:36,170 --> 00:34:39,870 692 00:34:39,870 --> 00:34:42,006 this Harvard branch is the one that I just made. 693 00:34:42,006 --> 00:34:43,380 So we can actually deploy it now. 694 00:34:43,380 --> 00:34:46,239 So I'm going to go ahead and deploy it to production. 695 00:34:46,239 --> 00:34:49,170 So deploy classroom/harvard. 696 00:34:49,170 --> 00:34:55,030 697 00:34:55,030 --> 00:34:58,570 Now, hopefully I don't break the whole thing. 698 00:34:58,570 --> 00:35:01,249 It's deploying. 699 00:35:01,249 --> 00:35:03,040 And then once it's finished, I can actually 700 00:35:03,040 --> 00:35:08,320 go to the public GitHub Classroom website and take a look. 701 00:35:08,320 --> 00:35:13,180 Presumably nothing has changed because we didn't actually 702 00:35:13,180 --> 00:35:15,880 change anything in the-- 703 00:35:15,880 --> 00:35:17,470 we didn't turn the feature toggle on. 704 00:35:17,470 --> 00:35:19,345 So we just put some code out there that's now 705 00:35:19,345 --> 00:35:23,492 integrated with our codebase, but it's not publicly-- 706 00:35:23,492 --> 00:35:24,700 it's not running for anybody. 707 00:35:24,700 --> 00:35:27,491 And then we'll go and enable it and kind of walk through the steps. 708 00:35:27,491 --> 00:35:36,042 709 00:35:36,042 --> 00:35:36,750 Takes the moment. 710 00:35:36,750 --> 00:36:08,167 711 00:36:08,167 --> 00:36:11,250 So in the meantime, while it's doing that, I'll kind of walk through-- oh, 712 00:36:11,250 --> 00:36:12,514 it's finished. 713 00:36:12,514 --> 00:36:15,380 714 00:36:15,380 --> 00:36:16,160 There we go. 715 00:36:16,160 --> 00:36:18,350 John's production deployment of Harvard is done. 716 00:36:18,350 --> 00:36:20,090 Great, took 80 seconds. 717 00:36:20,090 --> 00:36:21,880 So I can say classroom.github.com. 718 00:36:21,880 --> 00:36:25,820 719 00:36:25,820 --> 00:36:26,540 App is running. 720 00:36:26,540 --> 00:36:28,567 It's not broken. 721 00:36:28,567 --> 00:36:29,150 I can sign in. 722 00:36:29,150 --> 00:36:33,750 723 00:36:33,750 --> 00:36:35,410 I can see my normal classroom. 724 00:36:35,410 --> 00:36:37,150 There's no link about any of this stuff. 725 00:36:37,150 --> 00:36:40,120 Because I'm a staff member, I can go in here and click on this 726 00:36:40,120 --> 00:36:41,834 and go to the features thing. 727 00:36:41,834 --> 00:36:43,750 You can see we have some real features in here 728 00:36:43,750 --> 00:36:46,150 about deadlines, student identifiers, different kinds of features 729 00:36:46,150 --> 00:36:47,275 we've been adding recently. 730 00:36:47,275 --> 00:36:54,010 I can add a feature called Harvard and I can enable it for user 1. 731 00:36:54,010 --> 00:37:00,650 And now if I go to classroom.github.com, you'll see-- 732 00:37:00,650 --> 00:37:02,950 did I break it? 733 00:37:02,950 --> 00:37:05,560 Maybe I'm not user 1. 734 00:37:05,560 --> 00:37:09,030 We'll enable it for staff instead. 735 00:37:09,030 --> 00:37:12,942 736 00:37:12,942 --> 00:37:13,920 Oh, no. 737 00:37:13,920 --> 00:37:21,260 738 00:37:21,260 --> 00:37:26,450 The live demo failed for this, but I will-- 739 00:37:26,450 --> 00:37:29,010 you should believe me, it does work. 740 00:37:29,010 --> 00:37:30,260 We saw it work in development. 741 00:37:30,260 --> 00:37:34,310 So I'm just going to go ahead and do deploy classroom/master 742 00:37:34,310 --> 00:37:37,430 and put things back how they were. 743 00:37:37,430 --> 00:37:40,660 So that unlocked production. 744 00:37:40,660 --> 00:37:42,790 It redeployed the master branch out there. 745 00:37:42,790 --> 00:37:45,830 And this is actually like the demo didn't work, 746 00:37:45,830 --> 00:37:50,914 but it's a very similar experience to what would normally happen. 747 00:37:50,914 --> 00:37:52,580 I would test it on my local environment. 748 00:37:52,580 --> 00:37:53,390 It would work. 749 00:37:53,390 --> 00:37:54,650 I'd have my test run. 750 00:37:54,650 --> 00:37:55,670 The build would succeed. 751 00:37:55,670 --> 00:37:56,520 I would deploy it. 752 00:37:56,520 --> 00:37:58,860 I would go out and test it, make sure nothing is broken. 753 00:37:58,860 --> 00:38:00,620 If something's broken, I redeploy master. 754 00:38:00,620 --> 00:38:02,150 I go back into my development environment 755 00:38:02,150 --> 00:38:03,649 and try and figure out what's wrong. 756 00:38:03,649 --> 00:38:06,890 I don't know what I did wrong, but I'm not going to debug that right now. 757 00:38:06,890 --> 00:38:09,480 758 00:38:09,480 --> 00:38:12,710 So that's basically the standard flow going 759 00:38:12,710 --> 00:38:17,540 from just taking an open source project or a project working on with coworkers, 760 00:38:17,540 --> 00:38:22,220 doing a feature branching model, committing that stuff, 761 00:38:22,220 --> 00:38:24,920 sending it up to GitHub, and then deploying it. 762 00:38:24,920 --> 00:38:29,420 I think what we didn't do in the case of deploying to production, which I just 763 00:38:29,420 --> 00:38:32,900 wanted to reduce the amount of noise for my collaborators, 764 00:38:32,900 --> 00:38:36,360 was normally what I would have done is made a pull request in the production 765 00:38:36,360 --> 00:38:38,540 repo, had a discussion about the feature, 766 00:38:38,540 --> 00:38:41,520 but then that would create noise for the hundreds of people 767 00:38:41,520 --> 00:38:42,645 who are on that repository. 768 00:38:42,645 --> 00:38:47,200 So I just kind of went around that for demo purposes. 769 00:38:47,200 --> 00:38:50,450 But like we did on my fork, we can do a whole conversation 770 00:38:50,450 --> 00:38:53,190 about what the features were and how it worked. 771 00:38:53,190 --> 00:38:56,750 So that's what I had for that stuff. 772 00:38:56,750 --> 00:38:59,240 I wanted to go and offer up the opportunity 773 00:38:59,240 --> 00:39:03,710 for some questions around this flow, why we might choose certain things. 774 00:39:03,710 --> 00:39:06,778 So I'd kind of throw it out to you all. 775 00:39:06,778 --> 00:39:09,980 776 00:39:09,980 --> 00:39:10,680 No takers? 777 00:39:10,680 --> 00:39:11,532 There we go. 778 00:39:11,532 --> 00:39:14,484 AUDIENCE: Can you recommend a good resource for-- 779 00:39:14,484 --> 00:39:17,879 I see there's a lot of components in here, a lot of setup. 780 00:39:17,879 --> 00:39:18,670 JOHN BRITTON: Yeah. 781 00:39:18,670 --> 00:39:20,510 AUDIENCE: [INAUDIBLE] all of this-- 782 00:39:20,510 --> 00:39:22,380 JOHN BRITTON: Like the end to end thing? 783 00:39:22,380 --> 00:39:25,260 AUDIENCE: Yeah, is there like a book or does GitHub-- 784 00:39:25,260 --> 00:39:27,120 JOHN BRITTON: So I don't know about a book. 785 00:39:27,120 --> 00:39:30,780 I would point to Travis, which you're going to hear about next, 786 00:39:30,780 --> 00:39:32,670 as kind of the go-to place. 787 00:39:32,670 --> 00:39:33,950 I mean, there's other tools. 788 00:39:33,950 --> 00:39:36,000 I like Travis, but there's other tools out there. 789 00:39:36,000 --> 00:39:40,020 But go to them and you can basically see how to set all this stuff up. 790 00:39:40,020 --> 00:39:46,390 What's cool about it, too, is I'll just show you my Travis CI account for this. 791 00:39:46,390 --> 00:39:51,776 So I can go to my Travis CI account and basically I 792 00:39:51,776 --> 00:39:53,400 can list all of my GitHub repositories. 793 00:39:53,400 --> 00:39:57,120 And I just click a checkbox and it just automatically works. 794 00:39:57,120 --> 00:40:00,742 If you have any of the standard frameworks, 795 00:40:00,742 --> 00:40:02,700 so say you're using a Rails app, or a Node app, 796 00:40:02,700 --> 00:40:08,340 or basically every language framework combo has a testing system, if you 797 00:40:08,340 --> 00:40:11,820 use the standard thing, all you need to do is have one point of entry 798 00:40:11,820 --> 00:40:12,567 to run the tests. 799 00:40:12,567 --> 00:40:14,400 So in our case, we do everything in scripts. 800 00:40:14,400 --> 00:40:15,930 And we have script CI build. 801 00:40:15,930 --> 00:40:19,164 And that's just-- if you have that one file that will run the test, 802 00:40:19,164 --> 00:40:21,330 then Travis can figure everything out automatically. 803 00:40:21,330 --> 00:40:22,570 And you don't have to configure GitHub at all. 804 00:40:22,570 --> 00:40:24,570 You just log in to Travis, you click the button, 805 00:40:24,570 --> 00:40:26,430 and Travis configures GitHub for you. 806 00:40:26,430 --> 00:40:29,820 And I think that's the best way to get started is like go through their guides 807 00:40:29,820 --> 00:40:32,460 on CI/CD. 808 00:40:32,460 --> 00:40:36,870 There's also-- and I guess I should plug this as well-- 809 00:40:36,870 --> 00:40:39,522 developer.github.com. 810 00:40:39,522 --> 00:40:42,480 So if you want to be a bit more sophisticated, I know a lot of teachers 811 00:40:42,480 --> 00:40:48,240 are using this stuff for customizing the way that they have 812 00:40:48,240 --> 00:40:49,870 workflows for their students and stuff. 813 00:40:49,870 --> 00:40:53,161 But if you want to use this for your own projects and you want to customize it, 814 00:40:53,161 --> 00:40:55,090 you can just go to developer.github.com. 815 00:40:55,090 --> 00:41:00,360 Check out the API docs, and specifically this section here on the webhooks. 816 00:41:00,360 --> 00:41:03,420 What that does is it gives you basically a way 817 00:41:03,420 --> 00:41:07,800 to listen to events happening on GitHub.com and respond to them. 818 00:41:07,800 --> 00:41:10,770 So the most common event that people listen to is the push event. 819 00:41:10,770 --> 00:41:13,440 Anytime somebody pushes code to GitHub, GitHub 820 00:41:13,440 --> 00:41:16,290 will send a web request to a URL of your choosing 821 00:41:16,290 --> 00:41:17,760 and notify them of what's changed. 822 00:41:17,760 --> 00:41:19,343 And then you can build an integration. 823 00:41:19,343 --> 00:41:21,814 It does all kinds of stuff. 824 00:41:21,814 --> 00:41:23,730 So that's like if you want to get more custom, 825 00:41:23,730 --> 00:41:25,380 I would start on developer.github.com. 826 00:41:25,380 --> 00:41:27,171 If you want to have just standard thing, go 827 00:41:27,171 --> 00:41:31,270 to like Travis or another one of those services. 828 00:41:31,270 --> 00:41:33,020 And I should repeat the question, I guess. 829 00:41:33,020 --> 00:41:36,710 Or is-- the question that that answered was, 830 00:41:36,710 --> 00:41:39,074 is there a resource where I can get started? 831 00:41:39,074 --> 00:41:40,028 Yeah. 832 00:41:40,028 --> 00:41:44,808 AUDIENCE: Just trying to understand your deployment flow right there. 833 00:41:44,808 --> 00:41:47,188 You are sending a message from Slack to Hubot 834 00:41:47,188 --> 00:41:50,282 which is running some kind of a script which 835 00:41:50,282 --> 00:41:53,390 is kicking off your test in Travis and then deploying-- 836 00:41:53,390 --> 00:41:54,380 JOHN BRITTON: Well, the test happened first. 837 00:41:54,380 --> 00:41:56,963 So the question was, I want to understand the deployment flow, 838 00:41:56,963 --> 00:41:59,510 like what are the steps and what are the pieces? 839 00:41:59,510 --> 00:42:02,370 So first we write the code and we get the code hosted on GitHub. 840 00:42:02,370 --> 00:42:04,700 Then when the code gets pushed to GitHub, 841 00:42:04,700 --> 00:42:06,770 GitHub uses webhooks to trigger a build. 842 00:42:06,770 --> 00:42:09,012 That's all automatic, I don't do anything. 843 00:42:09,012 --> 00:42:11,720 Once the build is finished, or even before the build is finished, 844 00:42:11,720 --> 00:42:13,550 I can go into our chat channel. 845 00:42:13,550 --> 00:42:15,760 And that's actually one channel, education ops. 846 00:42:15,760 --> 00:42:17,900 It's all about this education stuff. 847 00:42:17,900 --> 00:42:23,000 And I just say, period deploy and the name of the app. 848 00:42:23,000 --> 00:42:26,150 And we have Hubot in the room listening to commands. 849 00:42:26,150 --> 00:42:28,820 So any person who's authorized to use Hubot, 850 00:42:28,820 --> 00:42:32,960 if they type a command in the channel, everybody can see it and Hubot sees it. 851 00:42:32,960 --> 00:42:35,960 And when Hubot sees it, that triggers a flow for Hubot. 852 00:42:35,960 --> 00:42:38,000 Hubot doesn't actually do the deploying. 853 00:42:38,000 --> 00:42:40,550 So this app in particular is hosted on Heroku. 854 00:42:40,550 --> 00:42:45,410 So what Hubot does is it tells Heroku to get this new version of the app 855 00:42:45,410 --> 00:42:48,494 and have it be deployed into our production pipeline. 856 00:42:48,494 --> 00:42:50,660 So Hubot is kind of like a little bit of glue there. 857 00:42:50,660 --> 00:42:55,352 And the part we need Hubot for is so that we can do it in the chat room. 858 00:42:55,352 --> 00:42:57,310 I could do this without being in the chat room. 859 00:42:57,310 --> 00:42:59,060 I could do it automatically when I deploy. 860 00:42:59,060 --> 00:43:01,805 And in fact, if I made a pull request with the changes 861 00:43:01,805 --> 00:43:04,430 and I just clicked Merge and I didn't talk to anybody about it, 862 00:43:04,430 --> 00:43:07,320 as long as the build passed, it would get deployed to production 863 00:43:07,320 --> 00:43:09,980 automatically without even talking to Hubot. 864 00:43:09,980 --> 00:43:13,880 When I said that you can actually deploy before the build passes, what'll happen 865 00:43:13,880 --> 00:43:22,220 is if you type in deploy the app name before it passes, then what will happen 866 00:43:22,220 --> 00:43:24,020 is Hubot will wait until the build passes. 867 00:43:24,020 --> 00:43:27,290 If the build fails, Hubot will tell you, sorry your build failed, 868 00:43:27,290 --> 00:43:28,460 fix your problems. 869 00:43:28,460 --> 00:43:31,610 Or your build succeeded, I'm deploying your app now. 870 00:43:31,610 --> 00:43:33,680 So it kind of always does that. 871 00:43:33,680 --> 00:43:37,010 Another kind of interesting component about that whole flow 872 00:43:37,010 --> 00:43:39,912 is GitHub is getting to be a larger company. 873 00:43:39,912 --> 00:43:41,370 There are a lot of engineers there. 874 00:43:41,370 --> 00:43:42,960 A lot of people working on GitHub.com. 875 00:43:42,960 --> 00:43:46,760 There can be a limitation on the number of people 876 00:43:46,760 --> 00:43:48,652 that be deploying at one time. 877 00:43:48,652 --> 00:43:50,360 So we've kind of developed like a queuing 878 00:43:50,360 --> 00:43:53,424 system, where it's like you get in line for your deployment. 879 00:43:53,424 --> 00:43:56,090 So basically, GitHub is constantly being deployed, like nonstop. 880 00:43:56,090 --> 00:43:57,830 Just deploy, deploy, deploy, deploy. 881 00:43:57,830 --> 00:44:03,150 Whenever the first deployment finishes, Hubot notifies the next person 882 00:44:03,150 --> 00:44:04,150 and starts their deploy. 883 00:44:04,150 --> 00:44:06,210 And there's just a whole process. 884 00:44:06,210 --> 00:44:10,070 They're always getting out there as fast as possible. 885 00:44:10,070 --> 00:44:12,568 Do we have any other questions from folks? 886 00:44:12,568 --> 00:44:18,190 887 00:44:18,190 --> 00:44:21,450 All right, well then I think that we may be finished up a little bit early. 888 00:44:21,450 --> 00:44:23,932 But thank you very much. 889 00:44:23,932 --> 00:44:24,890 Do you want to come up? 890 00:44:24,890 --> 00:44:26,240 BRIAN YU: Yeah, thanks so much. 891 00:44:26,240 --> 00:44:27,240 JOHN BRITTON: Thank you. 892 00:44:27,240 --> 00:44:29,165 [APPLAUSE] 893 00:44:29,165 --> 00:44:31,790 BRIAN YU: We'll go ahead and take about a 5 to 10 minute break. 894 00:44:31,790 --> 00:44:36,410 And then when we come back, we'll have Anna from Travis talking to us. 895 00:44:36,410 --> 00:44:37,406 OK, welcome back. 896 00:44:37,406 --> 00:44:40,280 Next up we're going to be talking a little bit about Travis CI, which 897 00:44:40,280 --> 00:44:44,060 you may recall from last week when we talked about testing in CI and CD 898 00:44:44,060 --> 00:44:44,780 for a bit. 899 00:44:44,780 --> 00:44:47,030 And so we have Anna here from Travis, who's 900 00:44:47,030 --> 00:44:49,510 here to speak with us about Travis CI. 901 00:44:49,510 --> 00:44:50,515 Turn it over to Anna. 902 00:44:50,515 --> 00:44:51,514 ANNA NAGY: Hi, I'm Anna. 903 00:44:51,514 --> 00:44:55,340 I'm a product manager and heading up involved in our education initiative. 904 00:44:55,340 --> 00:44:58,460 So I'm here to talk about continuous integration, which 905 00:44:58,460 --> 00:45:02,840 if you are involved in software already, you certainly probably have 906 00:45:02,840 --> 00:45:03,920 come across this. 907 00:45:03,920 --> 00:45:06,230 And I hope to go into enough detail that it's useful. 908 00:45:06,230 --> 00:45:10,100 If you haven't, we're going to start from the top. 909 00:45:10,100 --> 00:45:11,825 So I work at Travis CI. 910 00:45:11,825 --> 00:45:15,110 We are a leading continuous integration platform. 911 00:45:15,110 --> 00:45:17,780 It's essentially a tool for software engineers 912 00:45:17,780 --> 00:45:19,895 to maintain quality and collaboration. 913 00:45:19,895 --> 00:45:25,250 We started in 2011 in open source, moved to paid and enterprise over time. 914 00:45:25,250 --> 00:45:26,400 It's entirely GitHub-based. 915 00:45:26,400 --> 00:45:30,360 So your GitHub repositories talk to Travis if you would like them to. 916 00:45:30,360 --> 00:45:31,430 A bit of a side note. 917 00:45:31,430 --> 00:45:35,090 Microservices, Ruby Go, Ember.js, it's cool stuff. 918 00:45:35,090 --> 00:45:40,430 You can find us also on GitHub.com/travis-ci. 919 00:45:40,430 --> 00:45:43,370 Also, we do have an education program, just to plug it real quick, 920 00:45:43,370 --> 00:45:45,620 education.travis-ci.com. 921 00:45:45,620 --> 00:45:48,410 If you're on the GitHub Education pack, which you all should 922 00:45:48,410 --> 00:45:51,690 be if you have a dot edu, go sign up. 923 00:45:51,690 --> 00:45:53,330 We have an organization club. 924 00:45:53,330 --> 00:45:54,390 Contact us. 925 00:45:54,390 --> 00:45:57,530 And there was a question earlier, there are a couple of docs 926 00:45:57,530 --> 00:46:00,110 down there for getting started, kind of background and stuff. 927 00:46:00,110 --> 00:46:02,120 So all that stuff is there. 928 00:46:02,120 --> 00:46:06,620 But docs.travis-ci.com, it'll get you all there eventually. 929 00:46:06,620 --> 00:46:08,990 We also are involved in other education initiatives, 930 00:46:08,990 --> 00:46:13,220 so through Rails Girls Summer of Code have like a paid fellowship for women 931 00:46:13,220 --> 00:46:15,500 and non-binary engineers getting started. 932 00:46:15,500 --> 00:46:17,580 So highly recommend. 933 00:46:17,580 --> 00:46:19,890 Some general stats about us. 934 00:46:19,890 --> 00:46:21,980 We are smaller than GitHub, but it's pretty cool. 935 00:46:21,980 --> 00:46:26,600 So right now, 101.3 million repositories have built on Travis. 936 00:46:26,600 --> 00:46:31,620 About that many CI jobs, and that much compute time per month. 937 00:46:31,620 --> 00:46:35,410 So what exactly is happening in all of that? 938 00:46:35,410 --> 00:46:38,035 So to back up, why do you need CI? 939 00:46:38,035 --> 00:46:40,910 So imagine you have a project where you have to implement some stuff. 940 00:46:40,910 --> 00:46:41,743 Maybe it's homework. 941 00:46:41,743 --> 00:46:44,990 Maybe it's a product you're working on. 942 00:46:44,990 --> 00:46:46,400 You get this feature request. 943 00:46:46,400 --> 00:46:48,110 OK, we need to write this. 944 00:46:48,110 --> 00:46:49,160 You write it all at once. 945 00:46:49,160 --> 00:46:50,540 You try and fit it back in. 946 00:46:50,540 --> 00:46:54,164 And it always goes great, everything merges, it's fantastic. 947 00:46:54,164 --> 00:46:56,330 Generally there's some testing that needs to happen. 948 00:46:56,330 --> 00:46:57,704 Generally you end up with checks. 949 00:46:57,704 --> 00:47:01,505 Maybe you end up doing more and more shorter and shorter components, 950 00:47:01,505 --> 00:47:04,130 especially if you have multiple engineers working on a codebase 951 00:47:04,130 --> 00:47:05,340 together. 952 00:47:05,340 --> 00:47:08,320 Everyone's changes happening all at the same time 953 00:47:08,320 --> 00:47:10,770 is totally not a recipe for chaos. 954 00:47:10,770 --> 00:47:13,270 So this is where CI comes in. 955 00:47:13,270 --> 00:47:17,420 So continuous integration, integration being like let's get our changes in. 956 00:47:17,420 --> 00:47:20,150 Continuous being happening all the time. 957 00:47:20,150 --> 00:47:23,300 That said, as I go through this talk, there's 958 00:47:23,300 --> 00:47:25,240 a bit of phrase overloading here. 959 00:47:25,240 --> 00:47:29,570 So CI is both the process and the concept of continuous integration, 960 00:47:29,570 --> 00:47:33,260 like the best practice of moving stuff into the codebase over time, 961 00:47:33,260 --> 00:47:35,389 as well as like literally the tool. 962 00:47:35,389 --> 00:47:37,430 So when we say this project has CI, they probably 963 00:47:37,430 --> 00:47:40,190 follow CI best practices using a CI tool. 964 00:47:40,190 --> 00:47:44,420 So it's a bit of conflated terminology, but both 965 00:47:44,420 --> 00:47:47,060 refer to kind of the same thing. 966 00:47:47,060 --> 00:47:51,470 The biggest thing about CI that you talked about last week is testing. 967 00:47:51,470 --> 00:47:54,290 So I'm going to talk from an industry perspective. 968 00:47:54,290 --> 00:47:56,970 John Britton showed a little bit before. 969 00:47:56,970 --> 00:47:58,240 But testing. 970 00:47:58,240 --> 00:48:00,620 So code is tested, or it should be. 971 00:48:00,620 --> 00:48:01,970 If it's not, please write tests. 972 00:48:01,970 --> 00:48:03,470 It helps. 973 00:48:03,470 --> 00:48:06,440 It's a good idea. 974 00:48:06,440 --> 00:48:09,260 Or my favorite is the YOLO merge, where you just sort of send it 975 00:48:09,260 --> 00:48:10,360 to master and hope. 976 00:48:10,360 --> 00:48:11,450 Also good. 977 00:48:11,450 --> 00:48:15,080 But all modern testing language, in fact, even Fortran 978 00:48:15,080 --> 00:48:16,850 have testing frameworks. 979 00:48:16,850 --> 00:48:17,870 So use them. 980 00:48:17,870 --> 00:48:21,980 In JavaScript, there's Jasmine, Mocha, Jest, a bunch of others. 981 00:48:21,980 --> 00:48:26,070 Python has unit tests built into the standard library, 982 00:48:26,070 --> 00:48:28,360 but there's an interesting test runners. 983 00:48:28,360 --> 00:48:30,760 Nose test is one I've used. 984 00:48:30,760 --> 00:48:32,570 py.test is another. 985 00:48:32,570 --> 00:48:34,190 All sorts of good stuff. 986 00:48:34,190 --> 00:48:37,640 Many languages go, have tests built in. 987 00:48:37,640 --> 00:48:39,560 Ruby has RSpec. 988 00:48:39,560 --> 00:48:42,620 They all exist, so you can go and find them. 989 00:48:42,620 --> 00:48:43,640 Also, look up Fortran. 990 00:48:43,640 --> 00:48:46,400 It's kind of neat. 991 00:48:46,400 --> 00:48:47,225 So types of tests-- 992 00:48:47,225 --> 00:48:49,730 993 00:48:49,730 --> 00:48:52,510 you can look at it from a few different angles. 994 00:48:52,510 --> 00:48:55,640 And I am going to compress all of quality engineering 995 00:48:55,640 --> 00:49:00,977 into about five slides, so apologies to any quality engineers in the audience. 996 00:49:00,977 --> 00:49:02,810 It's a great spot if you're into automation, 997 00:49:02,810 --> 00:49:06,740 so your tests can go both into automated or manual tests. 998 00:49:06,740 --> 00:49:10,451 I'm going talk about automated tests, functional versus non-functional tests. 999 00:49:10,451 --> 00:49:12,700 Functional being like, we're going to test a function. 1000 00:49:12,700 --> 00:49:18,190 Nonfunctional being like, reliability, security, sort of operational things. 1001 00:49:18,190 --> 00:49:22,900 So automated-- the machine follows a script that you've written 1002 00:49:22,900 --> 00:49:25,460 or someone on your team has written. 1003 00:49:25,460 --> 00:49:29,290 And you assert an expected result and verify that the assertion is true. 1004 00:49:29,290 --> 00:49:33,610 Sort of like a programmatic version of checking a hypothesis, 1005 00:49:33,610 --> 00:49:35,840 only unlike physical and social sciences, 1006 00:49:35,840 --> 00:49:40,000 we're going to go back and change our results until we get the hypothesis. 1007 00:49:40,000 --> 00:49:41,840 Please don't do that, except here. 1008 00:49:41,840 --> 00:49:45,410 So we're going to set like, oh, this string, this output is true, 1009 00:49:45,410 --> 00:49:47,020 we expect it to be true. 1010 00:49:47,020 --> 00:49:51,820 It's not true, I'm going to go and fix my code until it is true. 1011 00:49:51,820 --> 00:49:54,730 So we're checking-- we'll write tests beforehand 1012 00:49:54,730 --> 00:49:57,580 or after-- beforehand's a good idea to check that things 1013 00:49:57,580 --> 00:49:59,950 are working the way they should. 1014 00:49:59,950 --> 00:50:02,350 As a side note, manual tests, this is literally someone 1015 00:50:02,350 --> 00:50:04,030 manually going in and checking. 1016 00:50:04,030 --> 00:50:06,700 Good idea to do it at times, but CI is really 1017 00:50:06,700 --> 00:50:09,250 concentrated on automated testing. 1018 00:50:09,250 --> 00:50:14,240 Then functional tests also are broken down into different categories. 1019 00:50:14,240 --> 00:50:17,650 So the root word function here is like programming functions. 1020 00:50:17,650 --> 00:50:19,520 We're going to test a function. 1021 00:50:19,520 --> 00:50:23,110 So there are subcategories, unit tests, integration tests, component tests, 1022 00:50:23,110 --> 00:50:24,460 others too. 1023 00:50:24,460 --> 00:50:27,849 This is a classic diagram I just felt like I had to throw in there. 1024 00:50:27,849 --> 00:50:29,140 You start with your unit tests. 1025 00:50:29,140 --> 00:50:31,030 Fail fast on the unit tests. 1026 00:50:31,030 --> 00:50:33,460 And then work your way up, such that a component test 1027 00:50:33,460 --> 00:50:36,100 tests like a package, a module, a larger part. 1028 00:50:36,100 --> 00:50:38,410 Integration test tests how things work together. 1029 00:50:38,410 --> 00:50:40,700 And end to end is like an entire flow. 1030 00:50:40,700 --> 00:50:44,110 So if you're writing a testing suite, a good idea is to start with unit tests. 1031 00:50:44,110 --> 00:50:47,750 Does this method work the way I expect? 1032 00:50:47,750 --> 00:50:48,989 So examples. 1033 00:50:48,989 --> 00:50:50,530 Here's a method out of our front end. 1034 00:50:50,530 --> 00:50:52,330 I will look at it later. 1035 00:50:52,330 --> 00:50:55,930 It's generating the build status badge. 1036 00:50:55,930 --> 00:50:58,410 I'll show it to you, but literally, the build is passing. 1037 00:50:58,410 --> 00:51:02,740 Let's make this into a markdown thing you can put into your GitHub read me. 1038 00:51:02,740 --> 00:51:04,340 That's our method. 1039 00:51:04,340 --> 00:51:05,232 Here's our test. 1040 00:51:05,232 --> 00:51:06,940 In a great irony of software engineering, 1041 00:51:06,940 --> 00:51:09,640 the test is longer than the method. 1042 00:51:09,640 --> 00:51:10,660 But it's good. 1043 00:51:10,660 --> 00:51:13,510 What it's doing is saying, OK, here's the assertion. 1044 00:51:13,510 --> 00:51:18,760 It generates a markdown image with a particular string that looks like this. 1045 00:51:18,760 --> 00:51:24,470 If this is changing, then we're going to fail for whatever reason. 1046 00:51:24,470 --> 00:51:29,290 So if this test passes, we haven't broken anything. 1047 00:51:29,290 --> 00:51:31,030 This is great. 1048 00:51:31,030 --> 00:51:35,050 If it hasn't, then maybe we need to go back and take a look. 1049 00:51:35,050 --> 00:51:38,740 Good things to test for, just backing up in general. 1050 00:51:38,740 --> 00:51:41,129 Things work the way they should, like a user 1051 00:51:41,129 --> 00:51:43,420 can see the things they are supposed to be able to see. 1052 00:51:43,420 --> 00:51:47,170 The string is generated the way we want the string to be generated. 1053 00:51:47,170 --> 00:51:50,150 Or things fail the way they should be failing. 1054 00:51:50,150 --> 00:51:52,900 A user can't see the stuff they're not supposed to be able to see. 1055 00:51:52,900 --> 00:51:56,950 That's a good one to keep in mind, because users should not 1056 00:51:56,950 --> 00:52:00,170 be able to see admin things and vise versa. 1057 00:52:00,170 --> 00:52:04,120 So the idea with testing is stuff should change only when you intend it to, 1058 00:52:04,120 --> 00:52:06,109 and you update the tests accordingly. 1059 00:52:06,109 --> 00:52:07,900 So if you write your tests beforehand, this 1060 00:52:07,900 --> 00:52:12,010 is a whole framework called TDD, Test-Driven Development. 1061 00:52:12,010 --> 00:52:13,930 Lots of folks use it. 1062 00:52:13,930 --> 00:52:16,300 So that way you know the code you are writing 1063 00:52:16,300 --> 00:52:19,750 matches the output you are expecting out of it. 1064 00:52:19,750 --> 00:52:23,590 Just a general statement is, it's really important 1065 00:52:23,590 --> 00:52:28,150 to keep in mind that unlike student work, or unlike personal work 1066 00:52:28,150 --> 00:52:31,600 even, software engineering tools are for teams. 1067 00:52:31,600 --> 00:52:35,950 So the testing is to help engineers keep stuff from breaking things that impact 1068 00:52:35,950 --> 00:52:38,800 other people, breaking production in unexpected ways so that when 1069 00:52:38,800 --> 00:52:43,060 the deployment goes, we don't-- this side issue has happened. 1070 00:52:43,060 --> 00:52:45,710 It can also function as a kind of documentation. 1071 00:52:45,710 --> 00:52:46,570 This is what I did. 1072 00:52:46,570 --> 00:52:48,597 This is what this method is supposed to do. 1073 00:52:48,597 --> 00:52:49,930 These are the results we expect. 1074 00:52:49,930 --> 00:52:52,190 And this is the stuff you can rely on. 1075 00:52:52,190 --> 00:52:55,494 So if there is no documentation in a repository, shake your head 1076 00:52:55,494 --> 00:52:56,410 and go read the tests. 1077 00:52:56,410 --> 00:52:59,200 1078 00:52:59,200 --> 00:53:05,830 So separating out-- so after we've gone through tests in-- 1079 00:53:05,830 --> 00:53:08,740 tests happen when we're doing a software build. 1080 00:53:08,740 --> 00:53:10,564 So we're going, I have this code. 1081 00:53:10,564 --> 00:53:11,230 I've written it. 1082 00:53:11,230 --> 00:53:12,460 I've written the tests. 1083 00:53:12,460 --> 00:53:20,137 We're going to then build this code, compile it maybe, prepare it, and turn 1084 00:53:20,137 --> 00:53:20,970 it out to the world. 1085 00:53:20,970 --> 00:53:22,300 So this is just-- 1086 00:53:22,300 --> 00:53:25,630 the next section just on builds and building. 1087 00:53:25,630 --> 00:53:28,760 Any burning questions in the meantime? 1088 00:53:28,760 --> 00:53:30,460 OK. 1089 00:53:30,460 --> 00:53:31,930 So builds and building. 1090 00:53:31,930 --> 00:53:35,974 Build can both be like a verb, like build this source code into something. 1091 00:53:35,974 --> 00:53:38,890 And this is really interesting, and I'm going to skip over this a lot, 1092 00:53:38,890 --> 00:53:41,380 but compiled versus interpreted languages. 1093 00:53:41,380 --> 00:53:44,680 So some languages need to be turned into a source code that is executable. 1094 00:53:44,680 --> 00:53:47,710 Others it's less clear cut. 1095 00:53:47,710 --> 00:53:52,180 So builds versus interpreter languages may jump straight into testing. 1096 00:53:52,180 --> 00:53:56,110 Sometimes there are optimizations that happen first. 1097 00:53:56,110 --> 00:53:59,440 This is some really cool stuff in computer languages. 1098 00:53:59,440 --> 00:54:01,190 This is also true. 1099 00:54:01,190 --> 00:54:03,610 So builds can get rather long. 1100 00:54:03,610 --> 00:54:07,450 This is the classic XKCD and I felt like I had to include it. 1101 00:54:07,450 --> 00:54:13,630 A build is also like the end result. So the build from yesterday was broken, 1102 00:54:13,630 --> 00:54:15,760 but today the build passed. 1103 00:54:15,760 --> 00:54:20,820 That refers to all of the change that happened between now and then. 1104 00:54:20,820 --> 00:54:24,970 So we can say the build as the end result of a build process. 1105 00:54:24,970 --> 00:54:28,490 So we went through the 10 minute build process, and then we have the build. 1106 00:54:28,490 --> 00:54:31,610 It functions as a kind of audit log. 1107 00:54:31,610 --> 00:54:39,320 So here you can see me going back and forth with our technical writer, 1108 00:54:39,320 --> 00:54:41,150 talking about-- 1109 00:54:41,150 --> 00:54:44,240 like this is actually a documentation discussion in which, 1110 00:54:44,240 --> 00:54:47,190 apparently, I had a really hard time with the passive voice. 1111 00:54:47,190 --> 00:54:51,230 So it was thought to look great. 1112 00:54:51,230 --> 00:54:54,530 There, in specific, it's highlighting the GitHub status checks. 1113 00:54:54,530 --> 00:55:04,610 So when we post to GitHub, we'll see both the positive status, 1114 00:55:04,610 --> 00:55:08,690 like yes this passed, the negative status, no this did not. 1115 00:55:08,690 --> 00:55:12,430 And it functions as kind of like a yes, this is what this commit did, 1116 00:55:12,430 --> 00:55:13,700 this is with that commit did. 1117 00:55:13,700 --> 00:55:15,820 GitHub is really nice and gives this in our UI, 1118 00:55:15,820 --> 00:55:23,802 but the general concept stays anyway that builds are highlighted and you-- 1119 00:55:23,802 --> 00:55:25,010 the statuses are highlighted. 1120 00:55:25,010 --> 00:55:26,521 You can see where it changed. 1121 00:55:26,521 --> 00:55:28,520 And I think the last one was a merge into master 1122 00:55:28,520 --> 00:55:31,910 in which we also fixed a hyperlink. 1123 00:55:31,910 --> 00:55:35,720 So why CI in general as entire systems as opposed to like, 1124 00:55:35,720 --> 00:55:39,110 why don't I have a single machine that just sort of we test on every so often? 1125 00:55:39,110 --> 00:55:40,460 It's to solve this problem. 1126 00:55:40,460 --> 00:55:41,810 Hey, it works on my machine. 1127 00:55:41,810 --> 00:55:42,800 It's going to be fine. 1128 00:55:42,800 --> 00:55:45,050 It's always fine. 1129 00:55:45,050 --> 00:55:47,760 And there are many different flavors of this problem. 1130 00:55:47,760 --> 00:55:50,960 So reproducibility. 1131 00:55:50,960 --> 00:55:54,770 Standard environments mean we can eliminate special customizations 1132 00:55:54,770 --> 00:55:57,000 and hacks from influencing the results. 1133 00:55:57,000 --> 00:56:00,260 So maybe you've installed additional dependencies, 1134 00:56:00,260 --> 00:56:03,140 maybe you have special scripts that when you know one thing happens, 1135 00:56:03,140 --> 00:56:04,779 go do the other thing. 1136 00:56:04,779 --> 00:56:07,820 If someone else doesn't have that, or even if your production environment 1137 00:56:07,820 --> 00:56:11,150 doesn't have that, then what? 1138 00:56:11,150 --> 00:56:15,630 Software is built on top of the entire ecosystem of dependencies below it, 1139 00:56:15,630 --> 00:56:17,505 so if those things don't exist, you might 1140 00:56:17,505 --> 00:56:19,880 have a failure in production that's really hard to debug, 1141 00:56:19,880 --> 00:56:22,272 because it works on my machine. 1142 00:56:22,272 --> 00:56:24,230 It also helps people check other people's work. 1143 00:56:24,230 --> 00:56:26,021 If we know the environment is standardized, 1144 00:56:26,021 --> 00:56:29,450 we have this clean installation, we know the environment is standardized, oh, 1145 00:56:29,450 --> 00:56:33,860 this build failed on this separate machine, it must be the code 1146 00:56:33,860 --> 00:56:39,860 or how we're working with this clean environment, which we can fix. 1147 00:56:39,860 --> 00:56:45,230 As opposed to, say we're working on an individual laptop. 1148 00:56:45,230 --> 00:56:47,540 Oh, let's all crowd around and try and figure it out 1149 00:56:47,540 --> 00:56:49,680 and hope it works in production. 1150 00:56:49,680 --> 00:56:55,490 So reproducibility is a big deal around CI systems 1151 00:56:55,490 --> 00:56:57,740 and why do we have external CI systems. 1152 00:56:57,740 --> 00:57:00,890 Also just a shout out-- collaboration is really important. 1153 00:57:00,890 --> 00:57:04,640 Because if we have these environments that we sort of can trust, 1154 00:57:04,640 --> 00:57:08,510 or at least can predict, people don't need access to the exact same things. 1155 00:57:08,510 --> 00:57:11,282 So I can go and work from wherever. 1156 00:57:11,282 --> 00:57:14,240 I can go and work from headquarters in Berlin, or I can come back here, 1157 00:57:14,240 --> 00:57:15,050 or whatever. 1158 00:57:15,050 --> 00:57:18,890 Because we're not necessarily looking at the exact same installations, 1159 00:57:18,890 --> 00:57:22,880 we have some reasonable, predictable environments, 1160 00:57:22,880 --> 00:57:24,890 other contributions can be included. 1161 00:57:24,890 --> 00:57:30,920 Also, this is a big deal in open source and corporations, 1162 00:57:30,920 --> 00:57:34,940 because of this wide distribution. 1163 00:57:34,940 --> 00:57:39,115 I also touched on it, really tidy deploys are a big deal for CI. 1164 00:57:39,115 --> 00:57:41,990 So a standard environment that looks like the production environment, 1165 00:57:41,990 --> 00:57:44,781 or even a standard environment that we can configure the production 1166 00:57:44,781 --> 00:57:47,330 environment to look like, any flavor of that, 1167 00:57:47,330 --> 00:57:50,780 it gives a better view of what will happen when the code is merged in. 1168 00:57:50,780 --> 00:57:55,459 You don't actually want to test on production most of the time. 1169 00:57:55,459 --> 00:57:56,750 It's one thing to feature flag. 1170 00:57:56,750 --> 00:58:01,460 It's another thing to do real live tests on production. 1171 00:58:01,460 --> 00:58:05,240 We would rather get our testing environments as close to production 1172 00:58:05,240 --> 00:58:08,030 as possible, as opposed to just, say we have customers, 1173 00:58:08,030 --> 00:58:11,520 hope that they don't see the problem. 1174 00:58:11,520 --> 00:58:14,600 It also helps, again, prevent forgotten customizations. 1175 00:58:14,600 --> 00:58:16,010 Oh, I had this machine. 1176 00:58:16,010 --> 00:58:19,957 Before the last Mac update, I installed this Ruby environment. 1177 00:58:19,957 --> 00:58:20,790 This happened to me. 1178 00:58:20,790 --> 00:58:23,540 I updated my operating system, now it's all gone. 1179 00:58:23,540 --> 00:58:26,010 Thank goodness I have another-- 1180 00:58:26,010 --> 00:58:27,900 I'm not testing on my own machine. 1181 00:58:27,900 --> 00:58:30,380 Otherwise that would have taken forever. 1182 00:58:30,380 --> 00:58:34,190 We also see things like faster development with CI systems. 1183 00:58:34,190 --> 00:58:37,470 So this was a really interesting study that we heard about, 1184 00:58:37,470 --> 00:58:40,370 which is that CI both improves confidence 1185 00:58:40,370 --> 00:58:44,870 in the code in an application and the pull request submitted to it. 1186 00:58:44,870 --> 00:58:47,930 So people, when there is CI, people feel better about the code 1187 00:58:47,930 --> 00:58:51,140 they are maintaining and they feel better about the pull 1188 00:58:51,140 --> 00:58:53,210 requests they are receiving. 1189 00:58:53,210 --> 00:58:57,860 So projects with CI will release about twice as often and pull requests are 1190 00:58:57,860 --> 00:59:04,430 accepted almost 2, but 1.6 hours faster, which is a big deal both in open 1191 00:59:04,430 --> 00:59:06,650 source-- that means people can contribute better-- 1192 00:59:06,650 --> 00:59:08,570 as well as in business. 1193 00:59:08,570 --> 00:59:14,810 That means you can move things along and people's valuable time is-- 1194 00:59:14,810 --> 00:59:17,250 you can get more distance from it. 1195 00:59:17,250 --> 00:59:19,660 There's a link there. 1196 00:59:19,660 --> 00:59:23,791 There are a lot of other interesting studies on CI out there as well. 1197 00:59:23,791 --> 00:59:25,290 My email is at the end of the slide. 1198 00:59:25,290 --> 00:59:27,623 I would love to send links later, but that's a good one. 1199 00:59:27,623 --> 00:59:29,880 1200 00:59:29,880 --> 00:59:34,040 Also, CI will then function as kind of this automation hub. 1201 00:59:34,040 --> 00:59:39,030 So I have this big, long list here of coverage tool, 1202 00:59:39,030 --> 00:59:40,620 of different things that will happen. 1203 00:59:40,620 --> 00:59:44,970 Code coverage being like, how much of our code is tested? 1204 00:59:44,970 --> 00:59:46,720 You may or may not want to test all of it. 1205 00:59:46,720 --> 00:59:51,960 Some of it is illogical to test, but some of it really should be tested. 1206 00:59:51,960 --> 00:59:54,480 Other things, linting does this following 1207 00:59:54,480 --> 00:59:56,460 the best practices for syntax. 1208 00:59:56,460 --> 01:00:00,720 Some languages will let you get away with syntax that you shouldn't, but it 1209 01:00:00,720 --> 01:00:04,020 does make it harder to maintain and harder to read. 1210 01:00:04,020 --> 01:00:07,230 Language run times-- does this run on Python 2.7, 1211 01:00:07,230 --> 01:00:11,820 does this run on Python 3.6, does this run on Python 3.5? 1212 01:00:11,820 --> 01:00:15,050 For libraries, this matters a lot. 1213 01:00:15,050 --> 01:00:19,090 So I have a library of Python tests. 1214 01:00:19,090 --> 01:00:20,760 Going to make sure this works. 1215 01:00:20,760 --> 01:00:24,399 Everyone is using everything in Python 3-whatever, so I'm going to test that. 1216 01:00:24,399 --> 01:00:26,190 I'm also going to backport it and just make 1217 01:00:26,190 --> 01:00:30,120 sure this runs on 2.7, because maybe someone's on it. 1218 01:00:30,120 --> 01:00:32,530 So you can do a lot of that with CI. 1219 01:00:32,530 --> 01:00:34,770 Then dependency management, configuration management, 1220 01:00:34,770 --> 01:00:37,680 these are all kind of, again, the libraries you're building on 1221 01:00:37,680 --> 01:00:42,030 or the deployments you're doing, and various other things. 1222 01:00:42,030 --> 01:00:44,295 I threw in some documentation generation. 1223 01:00:44,295 --> 01:00:46,170 There's some really cool frameworks for that. 1224 01:00:46,170 --> 01:00:50,110 Demo generation, really cool frameworks for that. 1225 01:00:50,110 --> 01:00:57,000 So this is where we start hooking up CI to CI, which we've talked about more. 1226 01:00:57,000 --> 01:01:01,320 So CD being either Continuous Delivery, this 1227 01:01:01,320 --> 01:01:04,200 is ready to be deployed whenever, or Continuous Deployment, 1228 01:01:04,200 --> 01:01:08,040 this is deployed all the time, GitHub style. 1229 01:01:08,040 --> 01:01:11,610 One way or the other, you need CI doing regular tests, 1230 01:01:11,610 --> 01:01:16,110 because if we say every commit is deployable, conceivably, 1231 01:01:16,110 --> 01:01:17,730 we could deploy every commit. 1232 01:01:17,730 --> 01:01:22,480 And if it's untested, we're back to the YOLO situation where we just hope. 1233 01:01:22,480 --> 01:01:26,250 That's the CI/CD interaction. 1234 01:01:26,250 --> 01:01:31,050 Also, CI jobs will often spawn automated deployments, right? 1235 01:01:31,050 --> 01:01:33,090 So hey, this passes. 1236 01:01:33,090 --> 01:01:33,730 I like it. 1237 01:01:33,730 --> 01:01:37,220 It's on the branch that we allow to deploy, let's just go an deploy. 1238 01:01:37,220 --> 01:01:42,150 That tends to be more in the continuous delivery category. 1239 01:01:42,150 --> 01:01:45,892 So tests ends up being really, really important. 1240 01:01:45,892 --> 01:01:48,600 If it's deployable every change or if it's deployed every change, 1241 01:01:48,600 --> 01:01:52,640 we want to have high confidence in the deployments we are doing. 1242 01:01:52,640 --> 01:01:56,120 So a couple examples, and you will see some familiar faces. 1243 01:01:56,120 --> 01:01:58,290 These are just literally some build configurations 1244 01:01:58,290 --> 01:02:01,110 I pulled out of open source so we can have a look at what exactly 1245 01:02:01,110 --> 01:02:03,590 is happening. 1246 01:02:03,590 --> 01:02:09,450 So CS50 manual, it was a fabulous little Travis YAML configuration to look at, 1247 01:02:09,450 --> 01:02:15,720 because OK, you can see the merge here. 1248 01:02:15,720 --> 01:02:20,760 David was merging in pull request about last week, I think. 1249 01:02:20,760 --> 01:02:22,510 And it was passing. 1250 01:02:22,510 --> 01:02:23,940 And this was the Travis YAML. 1251 01:02:23,940 --> 01:02:27,330 You can see the language, what version we're on, 1252 01:02:27,330 --> 01:02:29,340 any sort of caching that's happening. 1253 01:02:29,340 --> 01:02:33,690 The script is building that, making sure that the Jekyll build runs. 1254 01:02:33,690 --> 01:02:39,970 And does this Jekyll project properly turn 1255 01:02:39,970 --> 01:02:41,910 into the web page it's supposed to do? 1256 01:02:41,910 --> 01:02:43,990 If it works, we're going to do a deployment. 1257 01:02:43,990 --> 01:02:49,110 We're going to go to Elastic Beanstalk using this deployment process. 1258 01:02:49,110 --> 01:02:54,600 We're going to use these use secrets, which you can't see because it's 1259 01:02:54,600 --> 01:02:56,520 open source and it's hidden. 1260 01:02:56,520 --> 01:03:00,390 We're going to use these secrets to this part of AWS. 1261 01:03:00,390 --> 01:03:02,730 App is named this, like the whole thing. 1262 01:03:02,730 --> 01:03:06,327 And then in the last bit, we're going to notify a Slack room. 1263 01:03:06,327 --> 01:03:09,660 I assume there's a deployment Slack room or some interesting Slack room in which 1264 01:03:09,660 --> 01:03:12,960 everyone is cheering on the manual. 1265 01:03:12,960 --> 01:03:17,310 So we see CI both being like, hey, do this build, make sure it works. 1266 01:03:17,310 --> 01:03:21,720 Do this deployment, and also tell people it's done. 1267 01:03:21,720 --> 01:03:22,990 This is one of our projects. 1268 01:03:22,990 --> 01:03:26,610 This is one of the biggest Glue projects at Travis. 1269 01:03:26,610 --> 01:03:31,680 This is Travis Build, which takes this Travis YAML-- 1270 01:03:31,680 --> 01:03:34,330 this being a YAML configuration. 1271 01:03:34,330 --> 01:03:40,900 YAML is like this sort of key value configuration language. 1272 01:03:40,900 --> 01:03:44,330 So we're going to take Travis YAML and we're going to turn it to Bash. 1273 01:03:44,330 --> 01:03:48,670 Bash being a shell language which the build is actually executed in. 1274 01:03:48,670 --> 01:03:54,900 This is a big, long Ruby repository in which a bunch of things are happening. 1275 01:03:54,900 --> 01:03:59,520 This is the key part of this build. 1276 01:03:59,520 --> 01:04:02,070 So if we go back here, we have these three different tests. 1277 01:04:02,070 --> 01:04:05,460 We're going to deploy it to key.io. 1278 01:04:05,460 --> 01:04:07,520 And then there's an additional check these rate 1279 01:04:07,520 --> 01:04:11,790 tests that happens after that sadly didn't fit on my slides. 1280 01:04:11,790 --> 01:04:15,540 So again, here we're going to run these tests. 1281 01:04:15,540 --> 01:04:18,510 Beforehand, we're going to precompile and clean everything. 1282 01:04:18,510 --> 01:04:22,890 We're going to run the test, the spec tests. 1283 01:04:22,890 --> 01:04:26,130 Do an additional validation test that we've written ourselves. 1284 01:04:26,130 --> 01:04:30,750 And after deployment, we're going to send it to a Code Climate. 1285 01:04:30,750 --> 01:04:34,740 Code Climate being another tool for checking the health of your code. 1286 01:04:34,740 --> 01:04:37,380 There are all sorts of awesome tools out there, by the way. 1287 01:04:37,380 --> 01:04:39,713 I'm shouting at this one because it's in our repository, 1288 01:04:39,713 --> 01:04:42,540 but go find there's some awesome ones out there. 1289 01:04:42,540 --> 01:04:44,940 And then before the deploy, we're going to clean up. 1290 01:04:44,940 --> 01:04:49,410 And then ultimately, we end up deploying it. 1291 01:04:49,410 --> 01:04:56,750 So we have this project that goes from these individual steps, test test test, 1292 01:04:56,750 --> 01:05:00,840 to you clean up and get ready, deploy if it's the right kind, 1293 01:05:00,840 --> 01:05:03,290 and take it from there. 1294 01:05:03,290 --> 01:05:05,880 So I have a quick demo next. 1295 01:05:05,880 --> 01:05:08,600 Any questions before we get started? 1296 01:05:08,600 --> 01:05:11,799 OK, and let me make sure this works. 1297 01:05:11,799 --> 01:05:14,590 I thought I could only do one thing at a time, so I prerecorded it. 1298 01:05:14,590 --> 01:05:18,040 So I can pause if anyone has questions along the way. 1299 01:05:18,040 --> 01:05:21,970 So here we see my Travis account, my travis.org open source account. 1300 01:05:21,970 --> 01:05:27,220 I'm going to go and enable my demo Travis web project. 1301 01:05:27,220 --> 01:05:30,220 So I did this cooking show style because the build is a little bit long. 1302 01:05:30,220 --> 01:05:32,011 So here's the beginning of my pull request. 1303 01:05:32,011 --> 01:05:34,501 1304 01:05:34,501 --> 01:05:36,000 And there's the pull request itself. 1305 01:05:36,000 --> 01:05:38,130 I'm adding features. 1306 01:05:38,130 --> 01:05:41,850 I'm adding an emoji to the string here. 1307 01:05:41,850 --> 01:05:43,330 So you can see the first project. 1308 01:05:43,330 --> 01:05:45,480 I actually updated the test first, again, 1309 01:05:45,480 --> 01:05:50,370 so that I could know what the output was supposed to be right there. 1310 01:05:50,370 --> 01:05:55,200 There's two tests needed that updated, because they're checking the string. 1311 01:05:55,200 --> 01:05:56,010 Take it from there. 1312 01:05:56,010 --> 01:06:00,300 I'm going to go back, see if I'm remembering my demo. 1313 01:06:00,300 --> 01:06:06,570 I'm going to go back and head back over to my editor there 1314 01:06:06,570 --> 01:06:08,380 and actually update the code. 1315 01:06:08,380 --> 01:06:11,790 So now that I've done the test, I'm then going to update the code and say, 1316 01:06:11,790 --> 01:06:14,790 this is what is supposed to happen when you generate a markdown string. 1317 01:06:14,790 --> 01:06:18,060 You're supposed to also have that emoji. 1318 01:06:18,060 --> 01:06:20,910 And I pick tools because we're building things. 1319 01:06:20,910 --> 01:06:22,110 And see what emojis I like. 1320 01:06:22,110 --> 01:06:27,040 And now that we've done that, we're going to save it. 1321 01:06:27,040 --> 01:06:30,210 And I'm going to come over to my terminal. 1322 01:06:30,210 --> 01:06:32,730 That is my branch status. 1323 01:06:32,730 --> 01:06:34,290 You can see what's happening. 1324 01:06:34,290 --> 01:06:39,300 I'm going to add that file I have a terrible habit of get 1325 01:06:39,300 --> 01:06:41,790 add dot, which adds everything in the current directory. 1326 01:06:41,790 --> 01:06:43,950 Don't do that habit. 1327 01:06:43,950 --> 01:06:54,270 And then I'm going to commit it with a, hopefully, clear commit message. 1328 01:06:54,270 --> 01:06:57,660 I'm going to push that up. 1329 01:06:57,660 --> 01:07:02,940 This is just sort of the general commit, git commit and git management tools. 1330 01:07:02,940 --> 01:07:03,900 There are desktop apps. 1331 01:07:03,900 --> 01:07:05,810 I like my command line. 1332 01:07:05,810 --> 01:07:07,350 We're going to take it from there. 1333 01:07:07,350 --> 01:07:08,910 And now the build is going to run. 1334 01:07:08,910 --> 01:07:18,239 1335 01:07:18,239 --> 01:07:19,221 Build is running. 1336 01:07:19,221 --> 01:07:27,090 1337 01:07:27,090 --> 01:07:28,700 See my pull request. 1338 01:07:28,700 --> 01:07:29,990 That's my active branch. 1339 01:07:29,990 --> 01:07:33,180 There's my build history. 1340 01:07:33,180 --> 01:07:36,770 Apparently, I like gesturing with my cursor. 1341 01:07:36,770 --> 01:07:38,090 And it's coming in. 1342 01:07:38,090 --> 01:07:42,230 Travis will show the build in this current page once it has started. 1343 01:07:42,230 --> 01:07:47,139 So right now, the build is going from like a request coming into the Travis, 1344 01:07:47,139 --> 01:07:50,180 beginning of the pipeline, being parsed through things like Travis Build, 1345 01:07:50,180 --> 01:07:54,227 until the worker's ready to start. 1346 01:07:54,227 --> 01:07:55,310 And we take it from there. 1347 01:07:55,310 --> 01:07:56,730 And here is the build coming in. 1348 01:07:56,730 --> 01:08:01,220 So the first thing it's going to do is pull get chrome stable. 1349 01:08:01,220 --> 01:08:04,400 Like Chrome for the browser, but in headless browser mode so 1350 01:08:04,400 --> 01:08:07,700 we can test like that. 1351 01:08:07,700 --> 01:08:09,530 Taking a while. 1352 01:08:09,530 --> 01:08:17,640 And then it's going to set up assets where we turn this source code. 1353 01:08:17,640 --> 01:08:19,920 This is our entire front end, by the way. 1354 01:08:19,920 --> 01:08:24,590 If you go to Travis-CI/travisweb on GitHub-- 1355 01:08:24,590 --> 01:08:28,040 Travis-web on GitHub, I forked that project 1356 01:08:28,040 --> 01:08:30,830 and have done this on our open source front end. 1357 01:08:30,830 --> 01:08:34,010 So now it is building the front end, downloading 1358 01:08:34,010 --> 01:08:36,649 the build archive, which is the-- 1359 01:08:36,649 --> 01:08:39,620 some of these modules, some of these node modules 1360 01:08:39,620 --> 01:08:43,850 that were set up in the prior build. 1361 01:08:43,850 --> 01:08:47,300 There's a whole concept of, if you have dependencies 1362 01:08:47,300 --> 01:08:52,570 you can rely on, let's send them up to somewhere stable, in our case S3, 1363 01:08:52,570 --> 01:08:54,319 and pull them back down for the next build 1364 01:08:54,319 --> 01:08:56,930 so we don't have to pull it every time. 1365 01:08:56,930 --> 01:08:59,300 Now we're getting the Node version we need, 1366 01:08:59,300 --> 01:09:03,710 which is the underlying language here for this build. 1367 01:09:03,710 --> 01:09:06,680 Getting Node 5. 1368 01:09:06,680 --> 01:09:12,560 Installing the NPM modules, the Node modules that we need again. 1369 01:09:12,560 --> 01:09:14,120 And now we're linting. 1370 01:09:14,120 --> 01:09:17,399 So we're checking, does this exist the way it's supposed to, 1371 01:09:17,399 --> 01:09:20,120 is the syntax correct, all that good stuff? 1372 01:09:20,120 --> 01:09:23,330 Does it match the best practices? 1373 01:09:23,330 --> 01:09:26,390 And now we're building the website into something 1374 01:09:26,390 --> 01:09:30,950 that we can test automatically in the build. 1375 01:09:30,950 --> 01:09:36,770 So it is going from source code to testable situation. 1376 01:09:36,770 --> 01:09:40,040 We're doing that. 1377 01:09:40,040 --> 01:09:42,140 For better or for worse, I picked Travis Web 1378 01:09:42,140 --> 01:09:46,160 because it is a nice, clear JavaScript project you can go and look at. 1379 01:09:46,160 --> 01:09:49,100 It does have a fairly long build, so it will build for a little while. 1380 01:09:49,100 --> 01:09:52,010 1381 01:09:52,010 --> 01:09:53,960 For some background history, we picked Ember 1382 01:09:53,960 --> 01:09:59,630 because it works really well with our Ruby applications on the backend. 1383 01:09:59,630 --> 01:10:01,430 And we have this nice Ember project. 1384 01:10:01,430 --> 01:10:04,970 There are a lot of great JavaScript frameworks 1385 01:10:04,970 --> 01:10:07,270 that have come out recently, more recently. 1386 01:10:07,270 --> 01:10:08,800 Embers need to feel like Ember. 1387 01:10:08,800 --> 01:10:11,420 Highly recommend all these things. 1388 01:10:11,420 --> 01:10:14,540 Again, these are all ways of building applications, building 1389 01:10:14,540 --> 01:10:22,380 JavaScript applications, performant web apps in the browser. 1390 01:10:22,380 --> 01:10:25,410 So now we're generating-- yes, question. 1391 01:10:25,410 --> 01:10:29,280 AUDIENCE: So are you a contributor to Travis Web [INAUDIBLE]?? 1392 01:10:29,280 --> 01:10:31,490 ANNA NAGY: Um, let me pause real quick. 1393 01:10:31,490 --> 01:10:33,719 Oops, too much of a pause. 1394 01:10:33,719 --> 01:10:34,760 And we're back to being-- 1395 01:10:34,760 --> 01:10:36,260 I'll figure it out. 1396 01:10:36,260 --> 01:10:39,660 I contribute in different parts. 1397 01:10:39,660 --> 01:10:41,570 So I'm on the product and support side. 1398 01:10:41,570 --> 01:10:44,240 So odds and ends pull requests. 1399 01:10:44,240 --> 01:10:47,690 I do a lot of reading our code, because I end up explaining it to people. 1400 01:10:47,690 --> 01:10:51,260 So I pull request it to different configuration things I've set up, 1401 01:10:51,260 --> 01:10:53,220 different infrastructure things with people. 1402 01:10:53,220 --> 01:10:56,300 But I personally don't work on the Travis Web project. 1403 01:10:56,300 --> 01:10:58,562 A lot of cool people do. 1404 01:10:58,562 --> 01:11:00,270 But I'm happy to try and answer questions 1405 01:11:00,270 --> 01:11:02,870 if you've got questions about it. 1406 01:11:02,870 --> 01:11:04,370 So, yeah. 1407 01:11:04,370 --> 01:11:08,390 AUDIENCE: If your project was not on GitHub, can you use Travis? 1408 01:11:08,390 --> 01:11:11,540 ANNA NAGY: You cannot use Travis without GitHub. 1409 01:11:11,540 --> 01:11:15,660 Though you could if you have another source control project, 1410 01:11:15,660 --> 01:11:17,660 you could add a second remote and you would then 1411 01:11:17,660 --> 01:11:20,660 be testing off the GitHub remote. 1412 01:11:20,660 --> 01:11:23,820 It's a little iffy, but that is a way to do it. 1413 01:11:23,820 --> 01:11:27,765 But right now it is a continuous integration for GitHub projects. 1414 01:11:27,765 --> 01:11:30,140 We actually grew out of the GitHub open source community, 1415 01:11:30,140 --> 01:11:33,410 so we've stayed super true to that. 1416 01:11:33,410 --> 01:11:34,300 Other questions? 1417 01:11:34,300 --> 01:11:36,370 Otherwise I'll try to find my spot. 1418 01:11:36,370 --> 01:11:37,969 OK. 1419 01:11:37,969 --> 01:11:38,955 Let me see. 1420 01:11:38,955 --> 01:11:43,885 1421 01:11:43,885 --> 01:11:46,460 And I think it was like half way. 1422 01:11:46,460 --> 01:11:49,640 Oh, wow, that was pretty good. 1423 01:11:49,640 --> 01:11:52,670 So we're linting, going back to linting. 1424 01:11:52,670 --> 01:11:56,210 The next thing it will do is it will run all of the tests, 1425 01:11:56,210 --> 01:11:59,090 or after it builds it will run all of the tests. 1426 01:11:59,090 --> 01:12:03,500 I think I counted about 800 plus tests for all of these different things 1427 01:12:03,500 --> 01:12:05,250 in this entire front end. 1428 01:12:05,250 --> 01:12:06,670 I'll skip a little forward. 1429 01:12:06,670 --> 01:12:09,202 Oop, backward. 1430 01:12:09,202 --> 01:12:09,910 Sorry about this. 1431 01:12:09,910 --> 01:12:13,164 1432 01:12:13,164 --> 01:12:14,080 Let's skip to the end. 1433 01:12:14,080 --> 01:12:16,970 1434 01:12:16,970 --> 01:12:19,600 So I've skipped to the building step. 1435 01:12:19,600 --> 01:12:21,694 The dots here are the tests that ran and passed. 1436 01:12:21,694 --> 01:12:23,110 The stars are the ones we skipped. 1437 01:12:23,110 --> 01:12:26,810 Sometimes you want to skip tests, because whatever reason 1438 01:12:26,810 --> 01:12:28,790 that component's still under work. 1439 01:12:28,790 --> 01:12:32,760 It's not the best practice, but it is something that happens every so often. 1440 01:12:32,760 --> 01:12:37,610 So now we are building all these tests, all 847 last I checked, 1441 01:12:37,610 --> 01:12:40,090 and taking it from there. 1442 01:12:40,090 --> 01:12:40,852 Yes. 1443 01:12:40,852 --> 01:12:43,226 AUDIENCE: So here your [INAUDIBLE] is not actually Travis 1444 01:12:43,226 --> 01:12:45,480 and you're using some tests [INAUDIBLE]. 1445 01:12:45,480 --> 01:12:51,210 ANNA NAGY: Travis running the tests in-- 1446 01:12:51,210 --> 01:12:58,424 like running the NPM tests, the Node tests here. 1447 01:12:58,424 --> 01:13:01,060 There is a test runner that is executing these tests. 1448 01:13:01,060 --> 01:13:04,180 We are automating calling that test runner. 1449 01:13:04,180 --> 01:13:06,190 OK, so I'm going back to my pull request. 1450 01:13:06,190 --> 01:13:07,420 I'm saying it worked. 1451 01:13:07,420 --> 01:13:10,960 I'm checking it, all my checks have passed. 1452 01:13:10,960 --> 01:13:14,930 Because this is an individual pull request, I'm going to be wild and crazy 1453 01:13:14,930 --> 01:13:16,180 and merge my own pull request. 1454 01:13:16,180 --> 01:13:17,710 Highly recommend you get a review. 1455 01:13:17,710 --> 01:13:19,540 But I added three emoji. 1456 01:13:19,540 --> 01:13:20,230 It is OK. 1457 01:13:20,230 --> 01:13:21,620 It will survive. 1458 01:13:21,620 --> 01:13:25,210 So there is my pull request. 1459 01:13:25,210 --> 01:13:27,370 And went pretty quickly. 1460 01:13:27,370 --> 01:13:34,750 But in review, builds and testing in general, so the main goal 1461 01:13:34,750 --> 01:13:39,160 is to provide a way for tests to be run as development progresses, 1462 01:13:39,160 --> 01:13:40,360 rather than at the end. 1463 01:13:40,360 --> 01:13:46,630 CI came in as a theory in the '90s, but it's still 1464 01:13:46,630 --> 01:13:48,470 a best practice that is being adopted. 1465 01:13:48,470 --> 01:13:51,310 So we want tests to be run as the project is 1466 01:13:51,310 --> 01:13:54,720 going so that we don't get to these great merge days where we go, 1467 01:13:54,720 --> 01:13:56,830 OK, let's see if everyone's code fits together. 1468 01:13:56,830 --> 01:13:58,420 Oh my goodness, it doesn't fit together, now what? 1469 01:13:58,420 --> 01:14:00,628 Let's go back to the drawing board and figure it out. 1470 01:14:00,628 --> 01:14:03,032 You have all that time that both requires, 1471 01:14:03,032 --> 01:14:05,990 like we need to figure out this problem, but also, we did all this code 1472 01:14:05,990 --> 01:14:07,677 and maybe it needs to be changed. 1473 01:14:07,677 --> 01:14:08,760 Maybe it needs to go away. 1474 01:14:08,760 --> 01:14:11,790 If you do these small increments, test them as you go, 1475 01:14:11,790 --> 01:14:15,589 merge them in as you go, it's much more-- 1476 01:14:15,589 --> 01:14:17,380 you don't waste time in quite the same way. 1477 01:14:17,380 --> 01:14:18,200 It's much easier. 1478 01:14:18,200 --> 01:14:20,530 You can also predict what other teams are going to do, 1479 01:14:20,530 --> 01:14:23,260 because if you know everyone's tests are going to pass 1480 01:14:23,260 --> 01:14:27,640 or they're not going to merge it in, then you know that there's a-- 1481 01:14:27,640 --> 01:14:30,400 side effects are generally under control. 1482 01:14:30,400 --> 01:14:33,130 New features are tested with assuming the best practice 1483 01:14:33,130 --> 01:14:36,280 of writing the tests with the features. 1484 01:14:36,280 --> 01:14:40,630 And historical builds become a kind of living audit log for tests. 1485 01:14:40,630 --> 01:14:44,620 So yes, my build last month did this. 1486 01:14:44,620 --> 01:14:46,180 This is what the output is like. 1487 01:14:46,180 --> 01:14:48,910 Oh, we've changed it a lot, let me go back and compare. 1488 01:14:48,910 --> 01:14:53,290 Or the last build that was successful did this, that, and the other thing. 1489 01:14:53,290 --> 01:14:56,500 My tests, my project no longer is successful. 1490 01:14:56,500 --> 01:14:59,660 What specifically has changed here? 1491 01:14:59,660 --> 01:15:01,750 Let's go back and compare. 1492 01:15:01,750 --> 01:15:03,340 When were these things done? 1493 01:15:03,340 --> 01:15:06,240 Which commits had what status? 1494 01:15:06,240 --> 01:15:10,010 There's tons of good data, tons of good information. 1495 01:15:10,010 --> 01:15:12,430 And again, as you're doing your build, there 1496 01:15:12,430 --> 01:15:14,430 are lots of different types of tests to include. 1497 01:15:14,430 --> 01:15:19,450 So like the unit tests at the bottom, these are individual methods. 1498 01:15:19,450 --> 01:15:21,880 Component tests, integration tests, working your way up 1499 01:15:21,880 --> 01:15:25,210 until you're testing the bulk of an application. 1500 01:15:25,210 --> 01:15:27,520 Oftentimes people, again, will start with unit tests. 1501 01:15:27,520 --> 01:15:30,353 If the unit tests don't pass, you know particular methods are wrong. 1502 01:15:30,353 --> 01:15:32,620 Go and look at those. 1503 01:15:32,620 --> 01:15:38,200 And then it connects back into CI and CI/CD, both in open source 1504 01:15:38,200 --> 01:15:41,110 and in business and in industry. 1505 01:15:41,110 --> 01:15:43,980 So CI and CD are getting more and more common. 1506 01:15:43,980 --> 01:15:46,600 They are more or less considered a best practice, 1507 01:15:46,600 --> 01:15:49,780 though of course, every individual environment, 1508 01:15:49,780 --> 01:15:52,346 every individual corporation, every individual project 1509 01:15:52,346 --> 01:15:53,470 has different requirements. 1510 01:15:53,470 --> 01:16:00,590 So I don't want to be like CI is for everybody, but CI is for everybody. 1511 01:16:00,590 --> 01:16:03,760 So it's both like a trend and a best practice. 1512 01:16:03,760 --> 01:16:06,645 If you know your code is reliable at any given point, 1513 01:16:06,645 --> 01:16:08,770 and is tested and under control at any given point, 1514 01:16:08,770 --> 01:16:10,519 you can do all sorts of interesting things 1515 01:16:10,519 --> 01:16:14,020 around deployment, continuous deployment, other types of deployment, 1516 01:16:14,020 --> 01:16:17,380 changing around infrastructure, especially in cloud native and all 1517 01:16:17,380 --> 01:16:19,190 these cool stuff. 1518 01:16:19,190 --> 01:16:24,370 So teams will use CI and CD for testing and deployment, 1519 01:16:24,370 --> 01:16:26,260 also just general productivity. 1520 01:16:26,260 --> 01:16:28,060 CS50 is posting to a Slack room. 1521 01:16:28,060 --> 01:16:29,500 They're also all getting emails. 1522 01:16:29,500 --> 01:16:31,041 They could be posting somewhere else. 1523 01:16:31,041 --> 01:16:33,252 They could be notifying other things. 1524 01:16:33,252 --> 01:16:34,960 We could be going back and saying, oh, we 1525 01:16:34,960 --> 01:16:36,340 had an incident on our infrastructure. 1526 01:16:36,340 --> 01:16:38,080 This is not happening with the manual. 1527 01:16:38,080 --> 01:16:40,600 But say in another product we did an incident. 1528 01:16:40,600 --> 01:16:43,180 What happened to the tests most recently? 1529 01:16:43,180 --> 01:16:44,350 Can we fix this? 1530 01:16:44,350 --> 01:16:47,590 Oh, we need to fix this really quick. 1531 01:16:47,590 --> 01:16:49,600 Let's push this feature, make sure the test 1532 01:16:49,600 --> 01:16:52,640 passed before we end up with an incident on top of our incident. 1533 01:16:52,640 --> 01:16:56,240 So CI and CD are really deeply connected in that way, 1534 01:16:56,240 --> 01:16:58,690 either by making sure you can deploy whenever, 1535 01:16:58,690 --> 01:17:04,640 or deploying always on passing CI, like CS50 does. 1536 01:17:04,640 --> 01:17:05,900 So any questions? 1537 01:17:05,900 --> 01:17:10,460 This was like very high level, but I would love to talk more about it. 1538 01:17:10,460 --> 01:17:13,181 Questions, concerns either about Travis or-- yes. 1539 01:17:13,181 --> 01:17:17,420 AUDIENCE: Is there a particular reason that you rebuilt the environment 1540 01:17:17,420 --> 01:17:22,000 every time a new commit is pushed versus keeping something hot and ready to go? 1541 01:17:22,000 --> 01:17:24,830 ANNA NAGY: Yeah, so we do a bit of a mix of that with the caching. 1542 01:17:24,830 --> 01:17:27,470 But the rebuilt environment every time does deal 1543 01:17:27,470 --> 01:17:31,200 with changes to those environments. 1544 01:17:31,200 --> 01:17:35,346 So either-- like from our infrastructure side 1545 01:17:35,346 --> 01:17:37,220 or from like your libraries and dependencies? 1546 01:17:37,220 --> 01:17:38,600 AUDIENCE: Infrastructure. 1547 01:17:38,600 --> 01:17:39,308 ANNA NAGY: Right. 1548 01:17:39,308 --> 01:17:43,490 So we actually have a fairly continuous infrastructure project, infrastructure 1549 01:17:43,490 --> 01:17:45,510 deployment, so we do that. 1550 01:17:45,510 --> 01:17:52,044 It also works so that as we are changing our infrastructure, as we 1551 01:17:52,044 --> 01:17:54,710 are changing-- like we'll change infrastructure and Travis Build 1552 01:17:54,710 --> 01:17:57,110 at the same time, Travis Build being the runtime side. 1553 01:17:57,110 --> 01:17:58,860 So if there's a change to infrastructure, 1554 01:17:58,860 --> 01:18:00,151 we need to change Travis Build. 1555 01:18:00,151 --> 01:18:03,560 And so we have pretty continuous deployment. 1556 01:18:03,560 --> 01:18:06,640 We do have pre-built images. 1557 01:18:06,640 --> 01:18:13,294 So we kind of have these catch-all images of like ci-garnet covers like-- 1558 01:18:13,294 --> 01:18:14,960 I don't remember off the top of my head. 1559 01:18:14,960 --> 01:18:18,230 But it covers half a dozen languages and their various types. 1560 01:18:18,230 --> 01:18:22,070 ci-amethyst covers all the stuff on the JVM and their various types. 1561 01:18:22,070 --> 01:18:24,470 And so we will kind of have these catch-all images. 1562 01:18:24,470 --> 01:18:27,650 And then when you select a language, we'll pull in all the specific stuff 1563 01:18:27,650 --> 01:18:28,970 to it. 1564 01:18:28,970 --> 01:18:33,970 It also lets for better community involvement. 1565 01:18:33,970 --> 01:18:37,130 So we'll have like the D language contributes to Travis Build. 1566 01:18:37,130 --> 01:18:40,220 I personally have never written D, but it's a supported language. 1567 01:18:40,220 --> 01:18:43,304 1568 01:18:43,304 --> 01:18:43,970 Other questions? 1569 01:18:43,970 --> 01:18:44,607 Yeah. 1570 01:18:44,607 --> 01:18:47,876 AUDIENCE: We've had some issues, we also use a different CI. 1571 01:18:47,876 --> 01:18:51,804 So basically, if you make a change to say a read me file, 1572 01:18:51,804 --> 01:18:55,995 is there a way for Travis to know, oh, that's not going to break any tests, 1573 01:18:55,995 --> 01:18:59,120 so we shouldn't really be running all the tests based on this [INAUDIBLE]?? 1574 01:18:59,120 --> 01:19:00,286 ANNA NAGY: You can do like-- 1575 01:19:00,286 --> 01:19:03,814 1576 01:19:03,814 --> 01:19:05,300 it depends on the workflow. 1577 01:19:05,300 --> 01:19:06,409 So with Travis-- 1578 01:19:06,409 --> 01:19:07,700 I'm going to speak from Travis. 1579 01:19:07,700 --> 01:19:10,490 From Travis specifically, you could just skip the entire thing 1580 01:19:10,490 --> 01:19:14,890 by adding bracket skip space CI to the commit message. 1581 01:19:14,890 --> 01:19:16,970 So you could skip the entire thing. 1582 01:19:16,970 --> 01:19:23,160 You could set up a matrix build where you would set the environment variable. 1583 01:19:23,160 --> 01:19:27,710 So this type of change would have these kind of tests. 1584 01:19:27,710 --> 01:19:31,640 And then if we don't see any change or we want to pass it along, 1585 01:19:31,640 --> 01:19:34,315 we could do something different. 1586 01:19:34,315 --> 01:19:37,190 You could also get rid of it out of the read me on your pull request, 1587 01:19:37,190 --> 01:19:37,970 and then just-- 1588 01:19:37,970 --> 01:19:40,469 or get rid of it out of the Travis YAML in your pull request 1589 01:19:40,469 --> 01:19:41,870 and then put it back. 1590 01:19:41,870 --> 01:19:44,420 I would still say run the whole test suite though, 1591 01:19:44,420 --> 01:19:46,520 because you don't know what changed. 1592 01:19:46,520 --> 01:19:48,140 So different stuff. 1593 01:19:48,140 --> 01:19:51,150 But also, it will depend on project. 1594 01:19:51,150 --> 01:19:55,700 So we can talk more too afterward. 1595 01:19:55,700 --> 01:20:00,750 Other questions, other concerns about testing CI? 1596 01:20:00,750 --> 01:20:01,560 Other things? 1597 01:20:01,560 --> 01:20:06,600 I can talk a little bit about how we use Travis at Travis, which is kind of fun. 1598 01:20:06,600 --> 01:20:09,510 We've had different situations where in order to fix the builds 1599 01:20:09,510 --> 01:20:11,370 we have to pass a build, but the builds are stalled. 1600 01:20:11,370 --> 01:20:12,120 That's really fun. 1601 01:20:12,120 --> 01:20:14,970 1602 01:20:14,970 --> 01:20:17,706 Highly recommend that situation. 1603 01:20:17,706 --> 01:20:21,750 We dog food all of Travis, both Travis open source, close source, 1604 01:20:21,750 --> 01:20:22,720 and enterprise. 1605 01:20:22,720 --> 01:20:31,050 So you can't push a change to say Travis Build unless your Travis build passes. 1606 01:20:31,050 --> 01:20:35,270 So if you're changing it around, it gets super interesting. 1607 01:20:35,270 --> 01:20:36,910 Questions, concerns? 1608 01:20:36,910 --> 01:20:38,801 Otherwise I can call it early. 1609 01:20:38,801 --> 01:20:39,300 It was fast. 1610 01:20:39,300 --> 01:20:46,100 1611 01:20:46,100 --> 01:20:48,159 BRIAN YU: OK, well, thanks so much to Anna. 1612 01:20:48,159 --> 01:20:50,913 [APPLAUSE] 1613 01:20:50,913 --> 01:20:52,750 1614 01:20:52,750 --> 01:20:54,387 And with that, we'll wrap up for today. 1615 01:20:54,387 --> 01:20:56,470 And next week we'll dive to talk a little bit more 1616 01:20:56,470 --> 01:20:59,290 about scalability, and thinking about taking the web applications 1617 01:20:59,290 --> 01:21:01,164 we've been building just on our own computers 1618 01:21:01,164 --> 01:21:03,910 and how we might scale them to be larger applications used 1619 01:21:03,910 --> 01:21:06,160 by some number of more users. 1620 01:21:06,160 --> 01:21:08,010 Thank you so much. 1621 01:21:08,010 --> 01:21:10,848