1 00:00:06,970 --> 00:00:10,870 - The CICD acronym stands for: 2 00:00:10,870 --> 00:00:14,810 continuous integration, continuous deployment. 3 00:00:14,810 --> 00:00:17,520 And there are a number of different individual steps, 4 00:00:17,520 --> 00:00:21,840 or tasks, that can be part of that sort of pipeline. 5 00:00:21,840 --> 00:00:25,790 AWS code build is actually going to handle 6 00:00:25,790 --> 00:00:27,670 the first half of it. 7 00:00:27,670 --> 00:00:30,260 It is a region scoped resource, 8 00:00:30,260 --> 00:00:35,260 or resources, that manage the continuous integration part 9 00:00:35,360 --> 00:00:38,803 of continuous integration, continuous deployment. 10 00:00:39,830 --> 00:00:42,410 It allows you to perform actions 11 00:00:42,410 --> 00:00:45,099 like compiling your source code. 12 00:00:45,099 --> 00:00:49,080 It can also have a testing phase, 13 00:00:49,080 --> 00:00:51,410 so that after the compilation is done, 14 00:00:51,410 --> 00:00:54,440 you can actually verify that that package 15 00:00:54,440 --> 00:00:56,263 has been created properly. 16 00:00:57,770 --> 00:01:01,050 And it gives you the ability to create those packages. 17 00:01:01,050 --> 00:01:04,410 Now, it does not act as a persistence tier 18 00:01:04,410 --> 00:01:05,940 for those packages. 19 00:01:05,940 --> 00:01:08,810 There's another service in AWS that is dedicated 20 00:01:08,810 --> 00:01:12,970 specifically to that particular part of the process. 21 00:01:12,970 --> 00:01:17,160 But code build has a lot of other flexibility 22 00:01:17,160 --> 00:01:21,230 for custom jobs that might not have anything 23 00:01:21,230 --> 00:01:24,503 to do with packaging or compiling code. 24 00:01:26,200 --> 00:01:29,920 Now let's take a look at some of the features of code build. 25 00:01:29,920 --> 00:01:33,850 It allows you to create preconfigured environments 26 00:01:33,850 --> 00:01:37,430 for specific run times, or applications, 27 00:01:37,430 --> 00:01:39,223 like Java and so on. 28 00:01:40,910 --> 00:01:43,850 It has integration points with Jenkins. 29 00:01:43,850 --> 00:01:45,780 So if you're already using Jenkins, 30 00:01:45,780 --> 00:01:50,523 it's relatively easy to fit that into your CICD process. 31 00:01:52,140 --> 00:01:56,880 It uses a build spec file that is in YAML format. 32 00:01:56,880 --> 00:02:01,387 And this allows you to perform any layer of customization 33 00:02:01,387 --> 00:02:04,783 that is required within the individual steps. 34 00:02:06,270 --> 00:02:10,530 And finally, all artifacts that are created 35 00:02:10,530 --> 00:02:13,979 as part of the code build pipelines, 36 00:02:13,979 --> 00:02:17,683 are encrypted at rest using KMS. 37 00:02:18,910 --> 00:02:21,467 Now let's take a look at an example 38 00:02:21,467 --> 00:02:24,619 of where code build could be used 39 00:02:24,619 --> 00:02:28,543 in a slightly non-traditional way. 40 00:02:29,440 --> 00:02:31,560 Let's say that we would like to use code build 41 00:02:31,560 --> 00:02:33,630 to automate the deployment 42 00:02:33,630 --> 00:02:36,750 of schema changes to an RDS database, 43 00:02:36,750 --> 00:02:38,738 but we'd like to be able to validate 44 00:02:38,738 --> 00:02:42,803 and test from the application first. 45 00:02:44,120 --> 00:02:46,870 So, we start off with a schema change. 46 00:02:46,870 --> 00:02:50,340 and this might be just a, a sequel, file, 47 00:02:50,340 --> 00:02:53,560 or whatever we need to be able to apply 48 00:02:53,560 --> 00:02:56,683 to an existing database, to make the changes. 49 00:02:58,100 --> 00:03:02,590 This can be referred to as part of that build spec file, 50 00:03:02,590 --> 00:03:05,270 which we could even place in an S3 bucket 51 00:03:05,270 --> 00:03:07,733 alongside the schema change itself. 52 00:03:09,400 --> 00:03:14,400 Code build can then be instructed to launch an RDS database 53 00:03:16,810 --> 00:03:19,830 from a predefined snapshot, 54 00:03:19,830 --> 00:03:24,090 which we include as the before database, 55 00:03:24,090 --> 00:03:26,923 the one that's before the schema changes. 56 00:03:27,820 --> 00:03:31,797 And so code build can then restore that snapshot 57 00:03:31,797 --> 00:03:34,780 to a brand new RDS database, 58 00:03:34,780 --> 00:03:39,780 utilizing the AWS CLI, and potentially an S3 bucket, 59 00:03:41,090 --> 00:03:45,163 or an actual RDS snapshot, containing the data. 60 00:03:46,800 --> 00:03:51,800 Now, while that RDS snapshot restore is in progress, 61 00:03:52,530 --> 00:03:57,530 the code build job is going to wait until it completes. 62 00:03:58,830 --> 00:04:02,370 And there are a number of CLI options 63 00:04:02,370 --> 00:04:06,100 in AWS where you can issue a wait 64 00:04:07,380 --> 00:04:09,920 looking for a particular condition to be met. 65 00:04:09,920 --> 00:04:13,683 And that is very likely what this is using under the covers. 66 00:04:14,770 --> 00:04:17,510 Once the RDS database is fully deployed 67 00:04:17,510 --> 00:04:20,773 using the pre change schema, 68 00:04:22,080 --> 00:04:25,900 the code build job can then apply those changes 69 00:04:25,900 --> 00:04:28,060 to the RDS database, 70 00:04:28,060 --> 00:04:32,770 and potentially even use a cloud formation template 71 00:04:32,770 --> 00:04:36,433 to launch a temporary copy of the application environment, 72 00:04:37,400 --> 00:04:40,420 point it to the RDS database, 73 00:04:40,420 --> 00:04:42,880 and perform all of the validation that is required 74 00:04:42,880 --> 00:04:46,763 to make sure that the application is still fully functional. 75 00:04:48,580 --> 00:04:51,160 Once all of that is complete, 76 00:04:51,160 --> 00:04:53,650 we can then perform notifications, 77 00:04:53,650 --> 00:04:58,650 either through SNS or other mechanisms, to the end users. 78 00:04:58,740 --> 00:05:02,170 And, it can then clean up after itself 79 00:05:02,170 --> 00:05:04,928 by removing the RDS database instance 80 00:05:04,928 --> 00:05:06,733 that is no longer needed.