This article series focused on implementing a serverless CI/CD with AWS services, During the implementation process we are going introduce lots of ...
For further actions, you may consider blocking this person and/or reporting abuse
Hi! Thanks for your article. You mention that there are "2 parts", but I don't see the 2nd part posted. Did you ever write it? I was curious to see where you were going to go with the testing portion.
We fully utilize CodePipeline for all of our automatic deployments (managed via Terraform), and we're looking to add in jest testing. With your instructions, you're adding in the "testing" phase into the actual CodeBuild package building phase?
I tested the entire suite of the new AWS dev tools, what I can say so far is that it does not worth it. They are limited, hard to setup (lots of not documented errors) and if you do not deploy on EC2 instances you are looking for trouble.
I spent a few days on them for the AWS certificate, and I wouldn't return to them, at least for a few more years. A vanilla Jenkins have 2000% more features and less pains.
Is this because you're just used to Jenkins and not really open to learning AWS Code* in-depth? Do you think your experience would have differed had you had no previous knowledge of Jenkins?
I feel like your experience may be a bit biased leaning towards Jenkins.
It's 2019 and CodePipeline is still a toy, and I would say the architecture is fundamentally wrong.
A build system needs to monitor all branches and take most configuration from the repository itself (so that workflows can be modified in lockstep with development).
Also, you must offer status callbacks to enable branch protection. You can hack that in with Lambda, but it's a mess.
I think the state of CodePipeline in 2019 is that it is unsuitable for teams.
We use just CodeBuild for testing (on all branches), then CodePipeline on specific branches to do the actual deploy artifact builds and deploying them.
I agree that you definitely want to build & test all branches, but you can do that with CodeBuild without involving CodePipeline.
No, I don't like Jenkins per se, I just used it as an example because is the most popular way to do it.
We can compare it to GitLab tools and still you will notice that AWS Tools are just in their infancy.
With no CI/CD experience I would have been stuck in AWS console. I tried to use them in a non-conventional way, as in I didn't want to deploy in an EC2 behind a LB and the experience was terrible.
I guess they introduced more features meanwhile, maybe even Lambda.
AWS Cloud9 on the other hand, was a great experience, it just worked. But there again it is a polished mature product bought by Amazon.
@adrian ,
I completely agree with I faced many issue during learn AWS. AWS official website has all information but its scattered.
Great post Sagar!
I agree with some of the comments on how it's tricky to setup the AWS Code* tools. But if anybody is looking to extend this setup to create a CI/CD pipeline for monorepo apps deployed to multiple AWS accounts; we wrote about it here - seed.run/blog/how-to-build-a-cicd-...
@sagar
with Jenkins and GitHub, I can use Checks to show build status of current commit/PR.
How do you implement it with CodePipeline? Thanks.
There is no build in way to do it, so I created a Lambda function for it: github.com/fishbrain/codepipeline-...