使用AWS CodePipeline和Jenkins有什么优缺点?
我无法看到关于互联网的大量信息(https://stackshare.io/stackups/jenkins-vs-aws-codepipeline除外)。据我所知,它们如下:
AWS CodePipeline专业人士
AWS CodePipeline Cons
人们可以用来做出明智选择的其他主要差异吗?
答案 0 :(得分:2)
使用AWS CodePipeLine的其他缺点是缺少与GitHub之外的源控制提供程序的集成。我们唯一的另一个选择是创建启用版本的Amazon S3存储桶并在那里推送我们的代码。这会在Source控件和CodePipeline之间创建一个额外的图层。
此外,没有适当的文档可用于解释如何将代码推送到Amazon S3存储桶以获取内置常用平台(如.Net)的代码库。 AWS网站上给出的示例处理了一些随机文件,这些文件无济于事。
来自AWS CodePipeLine的 cons 部分的问题中缺少的另一个条目(平凡?)是Price。詹金斯是免费的。 Gitlab SCM解决方案现在由AWS https://aws.amazon.com/blogs/devops/integrating-git-with-aws-codepipeline/
提供答案 1 :(得分:1)
CodePipeline 和 Jenkins 可以完成同样的事情。此外,您不一定非要使用 CodePipeline 的 Web UI,它可以通过 AWS SAM CLI 模板进行设置,非常类似于 CloudFormation 模板。
CodePipeline 还支持很多源代码提供商,AWS CodeCommit、AWS S3、GitHub 和 BitBucket。
如果你在 AWS 工作,我个人更喜欢 CodePipeline,而不是 Jenkins。接口是 10 倍清洁 IMO。使用 SAM CLI 模板,您的管道可以作为代码进行管理,类似于您使用 Jenkinsfile 的方式。
答案 2 :(得分:0)
CodePipeline是一个连续的“部署”工具,而Jenkins更像是一个连续的“集成”工具。
持续集成是DevOps软件开发实践,开发人员定期将代码更改合并到中央存储库,然后运行自动构建和测试。
通过持续部署,可以自动构建,测试代码更改并将其发布到生产环境中。通过在构建阶段之后将所有代码更改部署到测试环境和/或生产环境,持续部署可在持续集成时进行扩展。
参考文献:
https://aws.amazon.com/devops/continuous-integration/
https://aws.amazon.com/devops/continuous-delivery/