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.
Software engineer with 4+ years of experience in building products for numerous domains like fin-tech, real estate, video streaming, retail, and now e-commerce.
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
@adrian ,
I completely agree with I faced many issue during learn AWS. AWS official website has all information but its scattered.
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.
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.
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.