AWS AMER Summit 2020 | CI/CD best practices for building modern applications

Aug 16, 2023

AWS AMER Summit 2020 | CI/CD best practices for building modern applications

Continuous integration and continuous delivery (CI/CD) techniques enable teams to increase agility and quickly release high-quality products. In this session, we walk you through best practices for building CI/CD workflows that enable you to manage your serverless and containerized applications. We cover infrastructure as code application models created using the AWS Cloud Development Kit, and we show you how to set up CI/CD release pipelines with AWS services like AWS CodePipeline and AWS CodeBuild.

Learn more about AWS Summits at https://amzn.to/2RaBsZI

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

#AWS #AWSEvents #AWSSummit

Content

0.28 -> [Music]

5.759 -> hey everybody

6.56 -> my name is andrew baird and really

8.24 -> appreciate your time joining my session

9.92 -> today

10.8 -> in this session we're going to talk

12.08 -> about ci cd best practices for modern

14.559 -> applications this is dev301

16.4 -> a little bit about myself i'm a

17.76 -> principal solutions architect with aws

19.76 -> i've been in this role for a little over

21.84 -> six years and i've been working with

23.119 -> enterprise size customers

24.8 -> in our atlanta georgia office and i've

26.56 -> got a developer background so helping

28.32 -> companies get to

29.76 -> modern architectures embracing

31.439 -> automation using development tools and

33.52 -> best practices has been a big passion of

35.12 -> mine in this role

36.079 -> i'm really happy and excited to talk to

37.6 -> you about some of the the great

39.6 -> practices and some of the thoughts that

41.04 -> we have around these

42.16 -> these paradigms and tools on aws so

44.879 -> let's jump in the agenda we're going to

46.16 -> talk about today

47.2 -> first i'm going to level set and talk

48.64 -> about some common nomenclature

50.719 -> make sure we're on the same page about

52.079 -> the way we define and talk about

54.239 -> continuous integration continuous

55.92 -> delivery or deployment

57.28 -> we're going to talk about how those

58.48 -> concepts apply to modern applications

61.28 -> then i'm going to break apart the the

62.879 -> sections of cincd and talk about some

65.119 -> specific services

66.56 -> and capabilities that aws offers to

68.72 -> really enable best practices in each of

70.64 -> those areas of the deployment life cycle

72.72 -> and then i'm going to wrap up with a

73.76 -> quick demo all right so let's jump in

76.24 -> foundational topics within ci cd

79.439 -> if you're familiar with the general ci

81.119 -> cd life cycle we like to break it apart

83.36 -> into these four main components of the

86.32 -> the actions that are taken on your

87.68 -> software as it's making it to production

89.6 -> um so obviously it begins with code

91.439 -> these are the activities that your

92.479 -> developers are hopefully performing

94.4 -> uh utilizing most of their time on day

96.159 -> to day they're writing code they're

97.28 -> getting it reviewed

98.32 -> and then once that code is ready to be

100.079 -> checked in

101.36 -> a build phase occurs and that code is

102.96 -> built and this is all of the activity

104.56 -> that happens hopefully through

105.52 -> automation

106.479 -> against that code to locally test it and

108.72 -> ensure it meets your quality bar

110.64 -> so that compilations succeed unit tests

114.079 -> occur the code coverage is there it's

117.2 -> linted for any style constraints that

119.2 -> you like to uh to hold your code to

121.6 -> and we make sure that there's a built-in

123.439 -> deployable artifact that's been tested

125.439 -> and vetted

126.32 -> by some local automation against that

127.84 -> artifact make sure it's ready ready for

129.599 -> deployment

130.64 -> then a test phase occurs where that

133.04 -> deployable artifact is going to be

134.56 -> introduced into

135.68 -> a real running environment hopefully

137.68 -> integrated with other components of

139.2 -> software that

140.239 -> other teams may own that you're

141.52 -> integrating with and you get a chance to

143.52 -> test it again

144.319 -> test it against those dependencies it

146.319 -> has the dependencies that

148.64 -> depend on your piece of software can

150.4 -> ensure that your code is

152 -> is still meeting their their

153.2 -> expectations and requirements and you do

155.2 -> a slew of

156.239 -> extra testing to make sure that that

158.48 -> artifact in a running environment is

160.08 -> behaving the way

160.959 -> functionally and you know performance

163.28 -> wise the way you expect it and then the

164.879 -> final step is a deployment to production

167.2 -> and the real key to all of these things

169.76 -> is to create feedback loops right that's

171.36 -> what all of these segments are about is

173.28 -> about creating a feedback loop as quick

174.959 -> as possible back to your developers

176.959 -> so that bugs and defects and functional

179.36 -> issues or operational issues are caught

181.36 -> as quick as they can as early as they

183.04 -> can be in this process

184.64 -> so that fixes kanakara and have them not

186.8 -> impact your business or or the writing

188.56 -> application for your users

191.2 -> aws provides a slew of different

193.44 -> services for each one of the segments of

195.519 -> this

196.48 -> sdlc and for those different uh

198.239 -> components and and uh points in time

200.239 -> across the

201.2 -> the stlc um so whether it's uh the code

203.84 -> that's being stored private git

205.04 -> repository sourced by code commit

206.959 -> all the way through how your code's

208.239 -> gonna be instrumented and uh

210.4 -> and monitored once it's running in

211.76 -> production through services like x-ray

213.519 -> and cloudwatch so we have

215.599 -> services to meet each one of the

217.04 -> different phases that your software is

218.4 -> going through and it's cicd

220.239 -> lifecycle and if you want to get a good

221.92 -> sense for how they all integrate

223.44 -> with each other together and you haven't

225.28 -> used any of them before

226.959 -> or you'd like to to start with a clean

228.959 -> slate to give you a really packaged

231.04 -> end-to-end working ci cd pipeline we

232.959 -> have another service that wraps them up

234.319 -> really neatly together in one place

235.68 -> called codestar

236.879 -> where you can see them all integrated

238.08 -> with each other and get a real working

240.08 -> integrated pipeline working

241.519 -> for your application from scratch okay

244.319 -> so now that we've got the baseline for

245.76 -> how we think about the different

247.2 -> phases within the sdlc let's talk about

249.84 -> modern applications

251.599 -> so modern applications the tenants that

253.36 -> they strive for aren't really any

254.799 -> different from

255.68 -> you know past moments in software

258 -> development history

259.199 -> it's all about delivering high quality

260.72 -> software that

262.8 -> is meeting the needs of your business

264.32 -> you strive for operational simplicity

266.8 -> you want to embrace automation

268.24 -> everywhere you can and you want to be

270.32 -> able to have an application that's well

271.919 -> understood operationally so you know

273.6 -> exactly how it's behaving

275.28 -> but the difference for how this is

276.88 -> implemented in a modern way

278.479 -> is the mechanisms with which you have to

280.88 -> achieve those tenants

282.479 -> have gone up you know many many fold in

285.44 -> the

285.759 -> the the last few years and we have

289.04 -> uh ci cd tooling to enable how fast

291.84 -> software can be delivered and

293.44 -> how iterable you're able to think about

294.96 -> how small those changes can be

296.8 -> different ways that software is deployed

298.96 -> with managed services and serverless

300.72 -> architectures microservices patterns

303.039 -> security being able to really be pushed

305.84 -> all the way down into your development

307.36 -> processes so that developers are the

308.88 -> ones who are baking security into their

310.639 -> applications

311.52 -> there's so there's just been a lot of

312.96 -> technology shifts that have happened

314.4 -> that pushed

315.199 -> all of the ability to deliver high

316.72 -> quality software in a modern application

318.56 -> closer and closer to developers

320.639 -> and in this session really just going to

322.24 -> focus on the cicd elements and

324.8 -> how that's enabled your developers to

327.759 -> achieve

328.479 -> using all the rest of the technologies

330.16 -> in the list with faster speed

332.4 -> able to you know deliver incremental

334.08 -> changes to your applications even faster

336.08 -> and have those feedback loops um close

338.16 -> back to your developers even quicker

340.08 -> even quicker so that problems can be

342.56 -> rectified and resolved hopefully before

344.32 -> they've even made it to production

346.479 -> and just to give you an idea of that

347.919 -> sense of speed that you're able to

349.28 -> achieve the agility that you're able to

351.84 -> uh pursue

352.88 -> as a result of of embracing cicd these

355.12 -> are some numbers that

356.4 -> were published by dora the devops

357.919 -> research and assessment group

359.52 -> um on kind of the difference that you're

361.68 -> able to to see

362.96 -> and the real change velocity and the

364.639 -> failure rates um for

366.24 -> development teams that are embracing ci

368 -> cd versus those that are not and

369.84 -> it's really drastic um you go from

372.08 -> deployment frequency that is weekly or

374 -> monthly to hourly or daily and think

375.759 -> about the competitive differentiation

377.44 -> that can give you

378.479 -> um both to you know outstretch your

380.24 -> competitors but also to react quickly to

382 -> your users and what they're telling you

383.36 -> about what they like or they don't like

384.639 -> about the experience they're having

386.8 -> so that lead time goes down really

388.24 -> really low the change lead time

389.919 -> different than deployment frequency is

391.36 -> how long does it take for a change that

392.88 -> i've contributed to make it out to

394.639 -> production

395.759 -> so getting that lead time down from you

397.52 -> know an order of months from when i've

399.12 -> written code

400 -> to my users are interacting with it down

401.759 -> to days where it's in their hands the

404.16 -> business is you know getting the benefit

405.84 -> of the time i've put into development

407.6 -> or i'm able to close the feedback loop

409.12 -> and not lose context on the changes that

410.8 -> i've made and the failures that might be

412.4 -> occurring as a result so i can fix them

414.639 -> without having lost context over a

416.479 -> really long period of time

418.96 -> and because those changes are smaller

420.4 -> you get really nice and

422.56 -> well reduced failure rates too those

424.4 -> feedback loops are closing continuously

426.639 -> earlier on in the development cycle so

429.199 -> that

430.08 -> the amount of failures that do occur are

431.919 -> smaller both in terms of impact as well

434.56 -> as volume

435.759 -> so you get a ton of benefits just by

437.52 -> pursuing ci cd it's really of all the

439.68 -> modern things you could be doing in an

441.12 -> application

442.319 -> architecture implementing automation for

444.319 -> your deployment and all of those

445.599 -> different stages is really the best

447.199 -> place to start

449.199 -> and a really unique point in history i

451.36 -> think that just to kind of really

452.72 -> emphasize this

453.759 -> is we're at a unique point in history i

455.44 -> think where there's still only 48

457.759 -> of teams that are really achieving these

459.36 -> numbers right not even in the majority

460.96 -> yet

461.36 -> um as of 2018 i'm sure that number

462.96 -> shifted over the past two years but

464.4 -> still

464.879 -> probably not by much and uh ci cd and

468.24 -> all the tooling available has gotten

469.919 -> gotten a lot of maturity over the past

471.36 -> few years as well there's tons of best

472.8 -> practices out there you could be

474.08 -> following

474.96 -> um and a lot of tools you can be taking

476.479 -> advantage of on places like aws

479.039 -> uh and and be learning from those that

480.879 -> have done it before you and getting all

482.56 -> these benefits so we're at this nice

483.759 -> inflection point where there's a lot of

485.12 -> maturity in this space

486.56 -> but still not even the majority of teams

488.319 -> that are taking advantage of it so

489.919 -> it's a really nice place to be where

491.28 -> there's a lot of impact that can be felt

492.72 -> still

494.319 -> all right so now let's talk about

495.599 -> specifically the different phases of ci

497.599 -> and cd and some of the the capabilities

499.599 -> of within aws that help address

501.84 -> uh the benefits and the actions that

503.599 -> happen within them

505.12 -> okay so continuous integration uh

507.52 -> implementing continuous integration

509.28 -> uh refers to the ability of having

511.28 -> source code changes that are checked in

512.959 -> checked into to code or positive

514.719 -> repositories be automatically uh picked

517.68 -> up

518 -> and built um so the idea that code is

520.88 -> checked in by a developer

522.159 -> it's introduced into a shared repository

524.159 -> where all the other developers code

525.519 -> who's

526 -> hopefully you know behaving nicely and

527.68 -> has met all your quality buyers

529.279 -> is now going to be introduced into that

531.92 -> that mainline build or release branch

533.68 -> what have you

534.56 -> and it's going to be built and unit

536 -> tested and made sure that it's met the

537.519 -> bar

537.839 -> so it hasn't been deployed yet we're

539.04 -> just making sure that the code that's

540.32 -> been written can be integrated

541.92 -> into the larger set of shared code that

544.16 -> the team has written

547.2 -> so just to really spell it out these are

549.2 -> the the same steps i just described but

551.12 -> the the main thing that i really want to

552.56 -> emphasize is that

553.68 -> immediacy of the feedback loop with

555.44 -> continuous integration

556.8 -> as soon as somebody's checked in if it's

558.399 -> automatically going to be picked up and

559.839 -> a unit test fails

561.68 -> or the the quality bar for code test

563.76 -> coverage hasn't been met or their style

565.92 -> issues of the way that that particular

567.519 -> developer has written the code

569.519 -> usually a build is something that can

570.959 -> happen within you know the order of

572.48 -> minutes

573.12 -> you know for really massive or

574.959 -> monolithic application maybe it takes

576.56 -> longer than that but

578.08 -> certainly in the order of hours at you

580 -> know even the the stretch

581.279 -> sizes for for some teams before that

583.44 -> feedback loop is closed but usually in

584.959 -> the order of minutes so

586.56 -> any developer that's contributed to code

588.24 -> change that's resulting in a build

590.24 -> that's not succeeding

591.68 -> or code test coverage that is slipping

593.519 -> lower than you want that bar to be set

595.12 -> at that developer is almost immediately

596.88 -> notified that there's an issue and they

598.399 -> can get back to work on fixing

600.08 -> um whatever the result could be so i i

601.92 -> did want to emphasize that

603.76 -> in this case for continuous integration

605.44 -> that feedback loop closes so quickly

607.92 -> that the benefits are extremely

609.76 -> important you don't have those cases

611.279 -> where

611.6 -> developers checked in code and it could

613.44 -> be a day or more

614.64 -> before they're notified and there's

615.839 -> other developers who are blocked with a

617.36 -> build that's broken

618.8 -> that they're not able to contribute to

620.079 -> or test out in a test environment

621.6 -> they're able to be notified immediately

622.959 -> that something they just contributed to

624.72 -> has an error in it encode pipeline is

627.92 -> the service on aws that plays the role

629.92 -> in automating how those code changes are

631.6 -> picked up

632.64 -> so it's a continuous delivery service

634.959 -> and

635.76 -> we're going to talk more about

636.72 -> continuous delivery later but in order

638.56 -> to even achieve continuous integration

640.24 -> there needs to be a service

642 -> that is responsible for automatically

644.88 -> picking up things

646.16 -> and pushing them through whatever your

647.519 -> ci or cd pipeline are going to achieve

649.92 -> so code pipeline is that cd service

652 -> that's going to kick off your continuous

653.519 -> integration step so it gives you a place

655.68 -> to model

656.48 -> all of the changes that are going to

657.519 -> occur hook into the various service that

660.48 -> are going to literally perform the

661.68 -> builds or the tests within your

663.04 -> environment

663.68 -> and then we'll talk more later about how

665.04 -> it integrates with

666.72 -> other things that exist further down on

668.32 -> the pipeline to to perform the real

670.079 -> deployments

671.6 -> and things like that so the way that

674.32 -> your continuous integration steps can

676.16 -> uh can be triggered code pipeline can

678.88 -> integrate with a variety of different

680.24 -> sources so they can either be code

681.519 -> centric sources

682.88 -> like code commit or github this is the

685.12 -> literal repository where your code is

687.04 -> stored

687.839 -> or you if you have your code stored in a

691.04 -> different type of repository that's not

692.64 -> get centric

693.6 -> or you're working with a type of

694.8 -> application artifact or existing build

696.64 -> processes

698.64 -> or code processes that don't hook in

700.8 -> neatly with those two you can

702 -> use an s3 model of integrating with code

705.2 -> commit where every time you've

706.64 -> you know packaged up some code artifacts

708.399 -> or a deployable unit and you want to

710.959 -> upload it to s3 that can be treated as

712.959 -> the initial trigger for code pipeline to

714.8 -> to kick off a pipeline execution as well

717.12 -> you've got both of those choices

719.2 -> so depending on the choice you choose

721.279 -> you can either pick a branch

723.44 -> within code command or github you choose

725.44 -> a specific object location in s3

727.519 -> and then the third option you have for

729.92 -> triggering a code pipeline deployment is

731.92 -> docker-centric so if you've got a

733.2 -> containerized application

735.04 -> you take that container image and you

736.72 -> push it to a specific tag for that image

739.2 -> to our elastic container registry

741.519 -> service

742.56 -> every time a new image gets pushed with

744.24 -> that tag code pipeline will recognize

746.399 -> that and trigger a build as well so

747.92 -> you've got these three different types

749.12 -> of options today

750.72 -> for for kicking off new builds or new

753.519 -> integrations or delivery pipelines with

755.6 -> with code pipeline

757.68 -> okay so just to really help visualize

760.399 -> for the containerized because that's a

761.519 -> demo i'm going to do later

763.279 -> you have a particular source code branch

765.6 -> called master

767.12 -> you've got a a tag that's called out for

770.079 -> ecr

770.72 -> that's called your release tag so either

772.16 -> one of those two could could be viable

774.48 -> um say you're you're deploying a new

777.04 -> container

777.839 -> um it's going to be running in our ecs

779.44 -> service just like my demo so you define

781.36 -> either one of those and if a code change

782.8 -> happens to my master code branch or if i

784.959 -> chosen

786 -> to build my image locally maybe you want

787.839 -> your developers to build and test

789.279 -> locally on docker with their laptops and

790.959 -> they'll push a new release tagged image

793.279 -> into ecr and that will trigger code line

795.839 -> to pick it up and push it to a build

797.44 -> stage and then

798.16 -> assuming the build succeeds a new and

800.88 -> another step will be defined in code

802.32 -> pipeline to deploy your

804 -> uh ecr image your docker image um to

807.04 -> to ecs now other than ecs

810.8 -> that's what i'll be demoing later you've

812.32 -> got a couple different options for how

813.68 -> that deployment's going to occur too you

815.2 -> can deploy

816.16 -> um ec2 centric applications on servers

819.199 -> you can deploy container-based

820.399 -> applications on ecs

822.399 -> fargate and it works with serverless

824.88 -> applications

826.48 -> using lambda as well so you have a slew

828.32 -> of different automatically

830 -> um supported natively supported uh

833.279 -> application architecture models um

835.279 -> deployment models that integrate with

837.12 -> with code pipeline

839.199 -> natively um and

842.56 -> aside from both uh aside from thinking

845.44 -> about the change triggering a code

847.199 -> pipeline

848.079 -> um execution from occurring you can also

850.24 -> think uh with other ways as well

851.92 -> so if you for whatever reason you want a

854 -> time-based

855.44 -> integration pipeline to be kicked off

856.88 -> you're not quite ready for every change

858.079 -> to be picked up automatically you can

859.519 -> use cloudwatch events

861.04 -> to trigger a code pipeline as well maybe

863.04 -> on a schedule

864.48 -> maybe on certain health events so if you

866.24 -> know there's a degraded

869.44 -> instance within your environment that

870.8 -> you want to trigger a new build on or if

872.56 -> a new

873.279 -> um deprecation notice comes for a

875.6 -> particular service that you're utilizing

877.279 -> like fargata for retiring a platform

879.12 -> version

879.6 -> you can utilize cloudwatch events to

881.04 -> trigger those um or you can use web

882.88 -> hooks so web hooks for a variety of

884.56 -> third parties can support

886.32 -> uh triggering code pipeline uh

888.16 -> executions as well

890.72 -> um so next i'm gonna focus on on

894.72 -> specifically the types of modern

897.76 -> architecture models on aws that play

900.959 -> well with these code

902.399 -> pipeline the cicd native services and

905.44 -> and what the specific integrations look

907.519 -> like with code pipeline

910.079 -> in order to leverage uh either

911.92 -> serverless or microservice based

913.44 -> architecture so the services i'm

914.8 -> speaking about

915.839 -> um are are lambda and fargate so both

918.399 -> are serverless in nature reduce the

919.839 -> management complexity you have

922.32 -> one is function based where you're

923.76 -> writing very minimal business logic

926 -> only code that is going to be deployed

927.68 -> as functional units functions on top of

930.079 -> aws lambda or on the other hand fargate

933.92 -> where you're going to be deploying

935.519 -> container-based applications but

938.16 -> the infrastructure is still fully

939.6 -> serverless and managed by the service so

942 -> two different options

943.199 -> both great approaches we're not going to

945.04 -> get into you know how to choose between

946.48 -> one or the other in this session there's

947.839 -> lots of

948.639 -> uh you know opinions you can read on the

950.24 -> matter and which is a better fit

952.16 -> brothers we have some high level details

953.759 -> listed here for

955.279 -> some ways you can think about the

956.399 -> different types of services but both are

957.92 -> great options

958.88 -> depending on your preference to to

960.48 -> deploy modern applications and i'm going

962.079 -> to talk about

963.199 -> kind of the model for integrating with

964.56 -> our ci cd services for both of those

967.68 -> and the the service where it's going to

969.199 -> really start getting specific because

970.639 -> code pipeline is just code whether your

972.24 -> code is destined for

973.68 -> um a container image or a lambda

975.6 -> function uh it's still code in the end

977.519 -> our developers written if you're hooking

979.12 -> into a git repository

982.24 -> the code pipeline is going to be

983.92 -> triggered in the same way as that code

985.44 -> is checked in so it's really code built

987.04 -> into build step

988.32 -> where you start seeing a divergence in

990.24 -> the paths for

991.519 -> how you're interacting with either

993.279 -> functions or containers

994.639 -> so code build is the service that plays

996.48 -> that automatic

997.92 -> build role within your ci cd pipeline on

1000.16 -> aws it's a fully managed build service

1002.16 -> it provides you

1004.079 -> build images that are able to be

1006.079 -> deployed on demand as changes occur

1009.12 -> you only pay for what you use so you

1010.72 -> don't have to have continuously

1012.079 -> available build servers anymore that

1013.519 -> you're paying for and maintaining and

1014.88 -> managing

1015.839 -> when a change needs to be built that

1017.36 -> build environment is stood up for you

1018.88 -> you only pay during the execution of

1020.56 -> that build and then it spins down

1022.399 -> uh when it's no longer needed um you can

1025.439 -> have those builds occur triggered based

1027.28 -> on

1027.919 -> um code pipeline executions like we've

1030.64 -> talked about but

1031.6 -> they can also be uh triggered within

1034.88 -> uh specific hooks themselves where if

1036.799 -> you want just the build to occur outside

1038.4 -> of a code pipeline execution every time

1040.079 -> a new

1041.679 -> commit is occurring against your

1042.799 -> repository that can happen as well and

1044.88 -> the important thing to emphasize here is

1046.48 -> that every one of those builds is going

1048.079 -> to run in a

1049.28 -> completely isolated brand new docker

1052 -> container environment so you don't have

1053.6 -> to worry about

1054.64 -> uh that environment changing from one

1057.44 -> build to the next

1058.96 -> um you know any any activities that

1061.36 -> happen as a result during that build

1063.039 -> like tests that have occurred or data

1064.799 -> that's

1065.36 -> needing to be manipulated within the

1067.28 -> environment during that test you start

1068.64 -> with a brand new fresh image

1070.72 -> every time that that build occurs every

1072.48 -> time a new build occurs

1073.84 -> um so that you can have a lot of faith

1075.52 -> and consistency and the builds that

1077.28 -> happen

1077.76 -> across all of your your different

1079.679 -> development changes

1081.76 -> um so say you were building a a lambda

1084.24 -> function

1085.28 -> this is an example of what is called a

1087.2 -> build spec file so that's the way that

1089.12 -> code build as a service is instructed

1091.28 -> um how builds occur for your application

1093.6 -> um so this looks like a javascript

1095.44 -> lambda function we've got a couple

1096.72 -> different commands that are going to run

1098.08 -> and the underlying build environment

1099.44 -> looks like a linux environment that's

1100.799 -> going to run

1101.52 -> a couple npm commands to you know check

1104.559 -> our code and to

1106.559 -> run the tests that i've configured in my

1108.24 -> code package and then it's going to use

1109.679 -> cloud formation and its package function

1111.6 -> functionality um to take the the lambda

1114.48 -> function code that i've got

1115.919 -> uh stored alongside this build spec file

1118.799 -> um and package it all up together and

1120.72 -> upload it to to s3

1122.64 -> as a zip artifact so um don't don't

1125.2 -> think too deeply there's tons of

1126.48 -> documentation on how these build spec

1128 -> files occur but just know that this is a

1129.76 -> file

1130.24 -> it's a yaml file that lives alongside

1133.039 -> your source code

1134.08 -> and when you perform that check in this

1136.16 -> build spec file is going to inform the

1138.559 -> code build service

1139.76 -> on what commands need to be executed in

1141.76 -> order for the build to occur for that

1143.52 -> application component

1145.12 -> okay if you're working with a

1147.6 -> containerized application

1149.52 -> a docker-based one this is an example of

1151.2 -> what a build spec file is going to look

1152.64 -> like

1153.28 -> um so for example here we're going to

1155.039 -> interact with our ecr service to

1157.36 -> get some credentials for the for the

1160 -> docker registry

1161.28 -> um so a boilerplate command there that's

1163.12 -> run to get us temporary docker

1164.48 -> credentials

1165.36 -> and then a couple docker-centric

1166.64 -> commands to to build a new image to tag

1168.72 -> that image and to push it into

1170.4 -> um to ecr so docker-centric commands but

1173.039 -> again it's just a simple file

1174.799 -> that lives alongside your source code

1176.4 -> and it informs the build environment

1178.559 -> the types of commands that need to be

1180 -> executed as part of a build for your

1181.76 -> application nothing more than that

1185.76 -> okay so just to recap continuous

1187.36 -> integration goals every time code

1189.039 -> changes occur

1190 -> new code is checked in it's going to be

1192 -> automatically picked up

1193.44 -> introduced into the shared code

1194.88 -> repository and kick off a new build

1197.28 -> now let's talk about continuous

1198.72 -> deployment so what to do with those you

1200.96 -> know ready

1202.08 -> ready to be deployed you know built

1203.679 -> artifacts and how to introduce them into

1205.12 -> an environment so

1206.159 -> continuous deployment for us is about

1208.48 -> automatically

1209.52 -> deploying changes as they're checked in

1211.6 -> through all of the build and test cycles

1213.2 -> all the way through to production

1215.36 -> continuous delivery for those that want

1217.039 -> to practice it is usually stopping at a

1218.88 -> lower life cycle environment

1220.08 -> a dev environment qa not all the way to

1222.64 -> deployment but

1223.52 -> very similar tenants involved but just

1225.44 -> the ability to have confidence in your

1226.96 -> testing the amount of

1228.4 -> you know test sophistication that you

1230.4 -> have to be confident to go all the way

1232 -> to production that's the big difference

1233.28 -> for continuous

1234 -> deployment so you want to automatically

1236.32 -> deploy changes to

1237.44 -> to all test environments trigger

1240.159 -> performance tests

1241.52 -> unit tests integration tests all of

1243.28 -> those things and once you're happy

1244.72 -> with all of those things you can deploy

1247.36 -> them to production

1248.559 -> and those feedback loops are important

1250.4 -> and obviously if you're going to deploy

1251.76 -> changes automatically to production it's

1253.76 -> really important that you have a

1254.72 -> feedback loop quickly

1256.159 -> if any deployment failures occur and you

1257.76 -> perform a rollback and not impact your

1259.36 -> customers too so just because you have

1260.88 -> continuous deployment doesn't mean that

1262.32 -> there's

1262.88 -> you know not a capability to to pull

1264.64 -> those changes out and and roll back

1266.4 -> automatically if anything has gone wrong

1268.64 -> um so the service from aws that's going

1271.039 -> to play a role there is called code

1272.32 -> deploy

1273.12 -> and it automates code to any type of

1276 -> instance any environment and to aws

1277.76 -> lambda

1278.4 -> and that doesn't just mean aws

1279.76 -> environments any vm based environment

1281.679 -> that can run the code deploy agent

1283.2 -> whether it's on your on-premises

1284.48 -> environment or elsewhere

1285.84 -> and the code deploy service can automate

1287.6 -> deployments to it and it handles the

1289.76 -> complexity of what has to happen in that

1291.6 -> infrastructure environment

1293.2 -> when a deployment occurs what does a

1294.799 -> deployment mean and it gives you a slew

1296.88 -> of different hooks and automation for

1298.96 -> the types of deployments that occur

1300.72 -> we're going to talk about blue green

1301.76 -> deployments in a minute but it has other

1303.44 -> options for rolling deployments all at

1305.039 -> once deployments

1306.24 -> and and all sorts of things to detect

1308.32 -> rollback and perform automation to make

1310.08 -> sure that your deployments go smoothly

1313.12 -> similar to the to the to the build spec

1315.36 -> file with the code build service that i

1317.039 -> described a second ago

1318.24 -> code deploy has another file it's called

1319.6 -> the app spec file um so this is going to

1322 -> be an ec2 based deployment it looks like

1323.679 -> we've got a linux environment

1325.36 -> we've got vms that are running a

1326.64 -> particular application and this app spec

1328.88 -> file is going to define the actu

1330.48 -> the actions that occur uh on a

1332.48 -> particular vm when a deployment is

1334.24 -> triggered so the

1335.12 -> code deploy service is going to for

1336.96 -> inform a particular vm

1339.039 -> that a deployment's been triggered and

1340.64 -> this abstract file is going to inform

1342.48 -> that

1343.039 -> uh that vm of all the steps that need to

1345.679 -> occur

1346.4 -> uh on on itself in order for the

1348.159 -> deployment action to take place it looks

1349.84 -> like we're copying some particular

1351.84 -> uh web app files from one directory to

1354.08 -> another

1355.6 -> uh we're going to set permissions on

1357.44 -> those files appropriately so

1359.039 -> you know the way that our application

1360.32 -> expects it and then finally we're going

1362.72 -> to

1363.2 -> uh run a slew of different deployment

1365.36 -> scripts that occur so it looks like

1366.559 -> we're going to deregister

1368.08 -> uh the the instance from the load

1370.159 -> balancer so it stops

1371.28 -> accepting requests we're going to run a

1373.679 -> kind of a deployment and web server

1375.44 -> start set of scripts

1376.64 -> and then once those things are done

1377.84 -> we're going to run another script to to

1379.28 -> locally test our site on the instance

1381.44 -> and then register it back with the load

1383.039 -> balancer so all of those hooks is just

1385.36 -> an order of

1386.159 -> execution steps of things that you want

1388.48 -> to you know shell commands or scripts

1390.32 -> that you want to execute

1391.919 -> within the deployment host that uh

1395.36 -> you know that create a deployment action

1396.96 -> for you okay nothing more than that so

1399.039 -> this is an app spec file

1400.4 -> and it also lives alongside your source

1402.159 -> code just like the build spec file does

1404 -> and when a deployment occurs in code

1405.36 -> deploy this app spec file defines what's

1407.2 -> going to happen

1409.679 -> the way that the deployments are

1411.36 -> targeted you've got again like i

1412.72 -> mentioned a couple different options

1414.96 -> for uh how quickly the deployment will

1417.28 -> will roll

1418.08 -> across your infrastructure um one at a

1420.799 -> time half at a time you can define that

1422.48 -> percentage or if it's just going to be

1423.84 -> an all at once deployment

1425.679 -> and then for targeting which bits of

1428 -> infrastructure that deployment needs to

1429.52 -> occur to where does this software change

1431.12 -> need to be deployed to you create what's

1432.48 -> called a deployment group

1433.919 -> um so depending on how you've organized

1436.4 -> your infrastructure different

1437.919 -> vpcs or it could be different subnets or

1440.24 -> you know it could be

1441.039 -> different aws accounts all together

1443.52 -> those code deploy agents that are that

1445.52 -> are running on your running

1446.64 -> infrastructure

1447.84 -> are going to define a collective set of

1449.84 -> infrastructure that's going to be

1450.88 -> deployed too

1452.88 -> for lambda-based deployments we're going

1454.799 -> to have a

1456 -> another app spec file but it's all it's

1458.32 -> going to do is inform the code deploy

1459.919 -> service that this is a

1461.039 -> serverless application running on

1462.559 -> functions a an optional

1465.039 -> parameter for what type of deployment i

1466.799 -> want to to

1468.4 -> execute with my lambda function and some

1470.88 -> more hooks

1471.84 -> around um you know monitoring the

1473.6 -> success of that deployment

1475.36 -> as well as um you know where testing and

1478.08 -> uh

1478.799 -> automation can occur before and after

1480.799 -> the deployment

1481.919 -> um so this this uh if you i'll go back

1484.08 -> and slide for a second if you saw the

1485.2 -> preference here a canary deployment

1486.96 -> that's going to do 10 for 10 minutes so

1489.12 -> what that means is that i've got a

1490.32 -> running function version v1

1492.32 -> i'm going to perform a canary deployment

1494.08 -> against v2 so i've got a second version

1496.159 -> of my code here

1497.36 -> and we're able to hit a hook using the

1500.24 -> code deploy service that before any live

1502.32 -> traffic is cut over to my v2 i'm able to

1504.4 -> run tests against that v2 version

1506.48 -> and once i'm happy with that test having

1508.24 -> been executed and it's been successful

1510.32 -> 10 percent of traffic is going to be

1511.679 -> shifted over to v2 and once v2

1514.559 -> has been running for 10 minutes with 10

1516.4 -> percent of the traffic

1517.84 -> uh and an alarm hasn't been triggered

1519.6 -> the rest of the 100 of traffic will

1521.36 -> automatically be shifted over to

1523.039 -> to v2 um so now that all of my traffic

1525.52 -> is being

1526.159 -> uh served by by v2 of my lambda function

1530.559 -> uh code code deploy also uh supports

1533.279 -> containerized applications so blue-green

1535.12 -> deployments

1536.159 -> um with ecs um so here's an example of

1539.12 -> what the app spec file looks like for

1540.799 -> ecs

1541.84 -> defines where my task definition is so

1543.679 -> that's you know the container images are

1545.2 -> inside that task definition and some

1546.559 -> resource information about those

1547.76 -> container images

1549.2 -> the load balancer associated with my

1550.96 -> deployment and again a list of hooks

1553.039 -> that represent lambda functions in

1554.72 -> reality and these are lambda functions

1556.72 -> that are going to be executed in

1558.08 -> sequence in each of those deployment

1559.44 -> steps to let me run some

1561.039 -> lambda-based automation to ensure my

1563.039 -> deployment is successful and tested and

1564.88 -> validated

1566.4 -> so let's visualize what this really

1567.84 -> looks like i've got a

1569.6 -> web application with traffic being

1571.039 -> served by an application load balancer

1572.96 -> i've got a listener and a target group

1574.559 -> running uh against my blue

1576.72 -> tasks we'll call them uh in target group

1579.44 -> one

1579.919 -> uh running on port 80. so with the way

1582.559 -> these blue green deployment deployments

1584.4 -> work is i set up a second listener on my

1586.24 -> load balancer with a different port so

1587.84 -> here i've got

1588.96 -> a test listener running on port 9000 and

1591.919 -> a second target group that

1593.52 -> receives traffic from that test listener

1595.6 -> so during a green task

1597.52 -> deployment we're going to deploy and run

1599.52 -> those green tasks but all of my product

1601.039 -> traffic is still hitting

1602.4 -> uh 100 the the blue tasks

1606.799 -> as those hooks run it's going to give my

1608.64 -> automation through lambda a chance to

1610.159 -> hit those green tasks

1612.08 -> even before any of the production

1613.52 -> traffic has been shifted so anytime i

1615.2 -> hit that test

1616.08 -> port port 9000 in my case i can you know

1619.279 -> have all of my test suites configured to

1621.12 -> hit port 9000 and that ensures that

1622.96 -> they're always going to run against the

1624 -> newly deployed test

1625.2 -> set of tasks and all the tests will go

1627.52 -> there and all of the traffic is still

1628.96 -> running on the already deployed blue

1631.36 -> blue tasks once i'm happy with those

1633.36 -> tests that have been run

1634.799 -> we're going to flip the production

1636.64 -> listener to now point at target group 2

1639.52 -> so that all of my tech my production

1641.52 -> traffic now is hitting those green tasks

1643.6 -> and those blue tasks are still up and

1645.52 -> running but they're not receiving any

1646.799 -> production traffic and you can define

1648.799 -> uh how long is that blue set of tasks

1651.039 -> going to run with connections draining

1653.12 -> and have them kept around to ensure that

1655.2 -> no alarms are breached everything is

1656.72 -> still successfully running with the

1658 -> green tasks

1659.12 -> and once you're happy with everything

1660.48 -> running you're able to you know fully

1662.96 -> switch over

1663.919 -> and everything is going to be running on

1665.279 -> the green tasks okay so a quick demo

1667.52 -> here i've got a

1669.12 -> a particular website and if you go to uh

1671.72 -> mythicalmisfits.com

1673.039 -> uh we have a workshop that's going to

1674.399 -> run you through building this

1675.52 -> application yourself too and i've

1676.72 -> modified the workshop

1678 -> to enable blue green deployment uh so

1680.32 -> i've got it running and deployed already

1682.159 -> and there's a couple issues that are

1685.44 -> preventing

1686.159 -> my misfits from running so you can see

1688.24 -> on the original version

1689.6 -> there's a slew of misfits um that you

1692.32 -> know i can sort

1693.52 -> i can sort and filter based on certain

1696.24 -> qualities they have

1697.279 -> and for some reason they're not able to

1699.919 -> load

1700.32 -> on my version of the deployed website i

1702.72 -> just checked the code change in

1704.159 -> so it was probably automatically

1705.44 -> deployed and the green version of my

1707.279 -> task

1708.08 -> of my tasks are unhealthy in my blue

1709.919 -> green deployment so let's take a quick

1711.279 -> look

1711.84 -> um i have a a code pipeline execution

1715.279 -> here and it looks like it's already

1716.48 -> automatically caught those failures that

1718.24 -> looks like 20 minutes ago and i was

1719.52 -> doing some testing so let's refresh here

1721.84 -> so we've got a a new deployment that's

1724.48 -> occurred in code pipeline

1726 -> uh and it's run through the build

1729.039 -> and this is going to describe all of the

1730.88 -> changes that have occurred

1732.32 -> um and when i go into code deploy

1735.36 -> um you can see the past deployments that

1737.2 -> have occurred

1738.72 -> so if i refresh this page you'll see a

1741.36 -> uh

1742.24 -> once it loads a couple failed

1744.559 -> deployments

1745.679 -> and it looks like it's just failed just

1748 -> failed recently and the reasons for its

1750.84 -> failure

1753.039 -> is because there was an invalid

1754.48 -> parameter exception um so all of these

1756.88 -> uh deployments that tried to occur uh

1759.6 -> even before i could get the

1760.88 -> the demo up and show it to you those

1762.32 -> those errors that i was inducing on my

1764 -> site were automatically caught

1765.919 -> by codeploy if i go to the alarm that's

1767.919 -> being viewed by

1769.12 -> by code deploy and i refresh this page

1770.96 -> you'll probably see some

1773.039 -> pass there so it looks like a particular

1776.88 -> error threshold was breached and that

1778.32 -> rollback was triggered but um just to

1780.64 -> kind of give you a view under the covers

1782.159 -> a little bit more on code deploy

1783.919 -> um so what i have here in code deploy i

1786.399 -> have an application created

1789.279 -> and i've pointed to a particular ecs

1791.6 -> service where that application

1793.039 -> deployment is going to occur

1795.679 -> this particular cluster this particular

1797.6 -> service so anytime that code pipeline

1799.84 -> deployment triggers a deployment

1801.52 -> within this application it's going to

1803.679 -> trigger a deployment against this ecs

1805.919 -> service

1807.12 -> if i scroll uh down to the particular

1810.48 -> deployment configuration

1812.799 -> or scroll down a little bit further you

1814.159 -> can see that i have an alarm configured

1816.08 -> here

1816.96 -> so that anytime this cloud watch alarm

1818.88 -> is going to get breached

1820 -> during a deployment it's going to

1821.6 -> automatically disable the deployment and

1824 -> perform a rollback

1825.2 -> um so it's in code deploy you were able

1826.96 -> to define you know what service is being

1828.48 -> deployed to what's the

1830.159 -> rate with which deployments are

1831.36 -> occurring and then you're going to be

1833.279 -> able to configure how to deployments

1834.88 -> automatically catch that

1836.399 -> the failures that occurred and a

1838.159 -> rollback's been performed

1839.679 -> so those are all the the pieces working

1841.44 -> together i'm going to jump back into the

1842.96 -> presentation and just give you a quick

1844.48 -> summary

1846.88 -> so again just a reminder here continuous

1849.44 -> deployment is about

1850.32 -> automatically picking up those changes

1853.2 -> and

1854.24 -> having them be deployed into the running

1855.84 -> environment not impacting customers

1858.08 -> changes that are found to be

1861.279 -> causing errors or issues or causing

1863.039 -> alarms to be triggered

1864.48 -> recognizing that and automatically

1865.919 -> performing a roll back and getting those

1867.519 -> feedback loops

1868.64 -> um created both in your software so that

1870.96 -> changes can happen automatically but

1872.48 -> back to your developers so that

1874.159 -> um you know deployments can be made more

1876.48 -> successfully more frequently

1879.279 -> and that's the the summary of continuous

1880.72 -> deployment so if you want to dive in

1882.64 -> more we have a ton of other resources

1884.399 -> available

1885.279 -> um all available on our website and

1888.559 -> at the url listed on the bottom here

1890.08 -> that will help you build

1893.279 -> modern applications following these

1894.799 -> modern methodologies and services that

1896.799 -> i've

1897.36 -> i've laid out here and please do look

1900.32 -> into our certification

1901.76 -> programs as well which have a ton of

1904.08 -> knowledge and best practices you can

1905.519 -> pursue and get certified in

1907.279 -> uh that will test your knowledge as it

1908.96 -> relates to these concepts like cincd

1912.24 -> and i thank you very much and that's the

1914.159 -> end of the session and again i hope

1915.519 -> you're enjoying the the virtual summit

1917.12 -> it's been a pleasure presenting to you

1919.2 -> and thank you again

1920.69 -> [Music]

Source: https://www.youtube.com/watch?v=Ptw9YjtddHg