1 00:00:00,880 --> 00:00:05,420 In the last section we started talking about how we're going to develop a development workflow that's 2 00:00:05,420 --> 00:00:10,880 going to allow us to develop our application test it in some fashion deploy it and then repeat that 3 00:00:10,880 --> 00:00:12,920 process all over again. 4 00:00:12,920 --> 00:00:17,170 So in this section we're going to start talking about some more specifics around that flow. 5 00:00:17,210 --> 00:00:19,060 Now I'm going to give you a diagram here. 6 00:00:19,070 --> 00:00:23,510 That's going to be just a little bit interactive so I'm going to add in a couple of elements as we go 7 00:00:23,510 --> 00:00:25,390 through this description over time. 8 00:00:25,400 --> 00:00:29,270 The important thing to keep in mind here around this diagram is that we're not going to talk too much 9 00:00:29,270 --> 00:00:31,420 about Dockers flow in this just yet. 10 00:00:31,430 --> 00:00:36,020 Instead I'm going to focus on telling you about some outside services in outside technologies that we're 11 00:00:36,020 --> 00:00:38,960 going to use to set up this development workflow. 12 00:00:39,200 --> 00:00:44,450 Once we kind of understand the core principles or the kind of design behind this development workflow 13 00:00:44,620 --> 00:00:49,220 we'll then can introduce stalker intel about how docker kind of facilitates everything. 14 00:00:49,580 --> 00:00:49,870 OK. 15 00:00:49,910 --> 00:00:51,810 So let's get to it. 16 00:00:52,310 --> 00:00:57,030 Our development workflow is going to revolve around creating a good hub repository. 17 00:00:57,150 --> 00:01:02,150 This repository is going to kind of serve as the central point of coordination for all the code that 18 00:01:02,150 --> 00:01:08,320 you and I are going to write and then eventually deploy to out some outside hosting service market hub 19 00:01:08,340 --> 00:01:14,240 repository is going to have two different branches one branch we're going to call the feature branch 20 00:01:14,570 --> 00:01:17,890 this feature branch is essentially a development branch of sorts. 21 00:01:17,900 --> 00:01:23,060 This is the branch that you and I are going to add code to make changes or do whatever it is we need 22 00:01:23,060 --> 00:01:25,500 to do to update our application. 23 00:01:25,520 --> 00:01:28,650 We're also going to have a master branch a master branch. 24 00:01:28,670 --> 00:01:33,980 It belongs to traditionally every get repository that might make our master branch is going to kind 25 00:01:33,980 --> 00:01:38,760 of represent our very clean working copy of our codebase. 26 00:01:39,080 --> 00:01:44,690 Any changes that we make to this master branch right here are going to be eventually automatically deployed 27 00:01:44,720 --> 00:01:46,770 out to our hosting provider. 28 00:01:47,240 --> 00:01:51,350 Let's now draw on a couple of arrows here to kind of walk through the process through which you and 29 00:01:51,350 --> 00:01:55,230 I are going to make changes to our code base and then eventually deploy those. 30 00:01:55,610 --> 00:02:00,350 So everything is going to start off with you and I on some local development machine like your desktop 31 00:02:00,350 --> 00:02:08,600 or your laptop you and I are going to pull all the latest code that we have from our feature branch 32 00:02:08,750 --> 00:02:13,370 and so we're going to imagine that maybe you are working on this project with some other engineer and 33 00:02:13,370 --> 00:02:18,110 maybe they have already published some amount of code on this feature branch. 34 00:02:18,110 --> 00:02:23,090 So you're going to pull down that code base and then on your laptop you are going to make some amount 35 00:02:23,090 --> 00:02:26,590 of changes to the application after you've made those changes. 36 00:02:26,600 --> 00:02:33,840 You'll then push those changes back up to the good repository again to the feature branch. 37 00:02:33,950 --> 00:02:36,930 You are never going to push code directly to master. 38 00:02:36,970 --> 00:02:43,090 You're only going to pull and push code from the feature branch once you push your changes up to this 39 00:02:43,090 --> 00:02:44,230 feature branch. 40 00:02:44,260 --> 00:02:47,430 You'll then create what is called a polar request. 41 00:02:47,500 --> 00:02:52,090 So we're going to make a pull request to take all the changes or all the new features you've added to 42 00:02:52,090 --> 00:02:57,400 this feature branch right year and merge them over to the master branch. 43 00:02:57,760 --> 00:03:05,300 So this kind of merging of code from feature over the Master is done by what we call that poll request. 44 00:03:05,530 --> 00:03:11,050 Now this pull request right here or this request to add some code from feature over to a master is going 45 00:03:11,050 --> 00:03:17,350 to set off a series of actions that are going to kind of govern how you manage your codebase. 46 00:03:17,390 --> 00:03:21,700 So once you create this pull request right here and then eventually merge it into master. 47 00:03:21,710 --> 00:03:24,260 Two very important things are going to occur. 48 00:03:24,530 --> 00:03:30,320 First off when you make this little pull requests we're going to set up a workflow that is going to 49 00:03:30,350 --> 00:03:37,550 automatically take our application and push it over to a service called Travis see-I Travis C.I. is 50 00:03:37,550 --> 00:03:39,690 a continuous integration provider. 51 00:03:39,720 --> 00:03:46,550 And essentially what they do is pull down your code and run a set of tests that you write on your code 52 00:03:46,550 --> 00:03:47,630 base. 53 00:03:47,690 --> 00:03:49,610 These are tests that you are going to write yourself. 54 00:03:49,610 --> 00:03:55,730 Now for your particular application or wherever you go and use this flow you'll end up using tests relevant 55 00:03:55,730 --> 00:03:58,680 to your particular application or whatever language you're working with. 56 00:03:58,940 --> 00:03:59,910 For our application. 57 00:03:59,990 --> 00:04:04,310 The one that we're going to kind of test this flow out on we're going to just be making use of a couple 58 00:04:04,310 --> 00:04:07,880 of pre-generated test so we don't need to worry too much about the testing for right now. 59 00:04:09,250 --> 00:04:15,730 Assuming that Travis is able to pull all the code from our master branch and run tests on it successfully. 60 00:04:16,000 --> 00:04:22,300 Travis C.I. is then going to be set up to automatically take our codebase take our entire project and 61 00:04:22,300 --> 00:04:26,480 push it over to some Amazon Web Services hosting. 62 00:04:26,500 --> 00:04:31,960 So essentially this entire flow is going to be depending upon you pushing some code up to this feature 63 00:04:31,960 --> 00:04:37,240 branch creating the puller request merging the request with the master branch and the instant you do 64 00:04:37,240 --> 00:04:40,360 that we'd run our tests if the tests run successfully. 65 00:04:40,390 --> 00:04:44,510 Travis see-I will automatically deploy your application to AWOS. 66 00:04:44,650 --> 00:04:46,520 So that is a flow in a nutshell. 67 00:04:46,530 --> 00:04:48,120 Now this flows a little bit complicated. 68 00:04:48,130 --> 00:04:51,630 So I want to talk about the entire flow again like from start to finish. 69 00:04:51,670 --> 00:04:55,870 One more time in a slightly different format just kind of a different diagram here. 70 00:04:55,870 --> 00:05:00,010 Just to give you kind of a different take on what's going on if you feel like you already understand 71 00:05:00,010 --> 00:05:00,630 this flow. 72 00:05:00,700 --> 00:05:01,530 That's totally fine. 73 00:05:01,540 --> 00:05:04,060 Take a pause right here and skip over to the next video. 74 00:05:04,060 --> 00:05:07,450 Otherwise we're going to give you essentially the same description again but with a different set of 75 00:05:07,450 --> 00:05:08,240 diagrams. 76 00:05:09,800 --> 00:05:10,190 All right. 77 00:05:10,460 --> 00:05:14,110 So we can kind of imagine that we're going to have three phases to our project here. 78 00:05:14,120 --> 00:05:20,040 We've got the death phase the testing phase in the production phase during the death phase. 79 00:05:20,060 --> 00:05:23,120 You and I are going to make some number of changes to our code base. 80 00:05:23,150 --> 00:05:27,540 And again these are all going to meet to a branch that is not the master branch. 81 00:05:27,590 --> 00:05:32,540 We're going to call it our feature branch because it's where we develop new features once we make our 82 00:05:32,540 --> 00:05:38,030 changes to that feature branch we're going to push our changes to get up and then we're going to create 83 00:05:38,060 --> 00:05:44,980 a pull request to merge with the master branch as soon as we make that pull request. 84 00:05:45,120 --> 00:05:50,760 We are going to set up Travis see-I to automatically pull that Master branch with the new and updated 85 00:05:50,760 --> 00:05:54,560 code Traviss then going to run our tests. 86 00:05:54,810 --> 00:06:00,180 If all the tests are executed successfully We're going to say great we can merge all the changes over 87 00:06:00,180 --> 00:06:02,400 to the master branch. 88 00:06:02,610 --> 00:06:05,470 We're going to again push our code over to Travis s.i. 89 00:06:05,610 --> 00:06:10,560 We're going to test run the tests one more time and then have Travis see-I automatically deploy our 90 00:06:10,560 --> 00:06:17,400 application over to AWOS services are essentially a very specific very specific service that is called 91 00:06:17,460 --> 00:06:18,870 elastic beanstalk. 92 00:06:19,230 --> 00:06:19,480 OK. 93 00:06:19,500 --> 00:06:24,810 So that's kind of the whole flow that we're going to go through here in two different diagrams. 94 00:06:25,260 --> 00:06:26,770 Let's take a quick pause right here. 95 00:06:26,850 --> 00:06:31,160 We're in come back the next section and start talking about how docker fits into all this stuff.