AWS CodePipeline面世
去年秋季，我们在 AWS re:Invent 大会上推出了 AWS CodePipeline （想要了解更多信息，请阅读我的博客贴- New AWS Tools for Code Management and Deployment 代码管理与部署新工具）。就像我当时所说的一样，这个工具将会帮助你实现软件建模与发布过程的自动化。CodePipeline所实现的自动化旨在使你的发布过程更加可靠高效。
现在可用
我非常激动，能够宣布CodePipeline现在可用的，你从今天起就可以开始使用它了。
在我开始讲解细节之前，我想与你分享一点背景故事。
CodePipeline的前辈-Pipelines
正如 AWS CodeDeploy 的开发是受一个名为Apollo的内部工具的启发一样（想要了解更多详情，请阅读 The Story of Apollo – Amazon’s Deployment Engine （Apollo的故事–亚马逊的部署引擎）），CodePipeline也有一位亚马逊内部的前辈。
我们测量代码被记录后，部署到生产环境所需的时间，然后构建自己的持续交付业务。这个时间显然太长，在开发团队尽快将特性交付到客户手中的各种努力中，这个时间是他们感受到的一项明显的挑战。
进一步的调查结果表明，这个时间的大部分并不是用在了实际的实施构建，运行测试，或进行部署上。相反，团队间手工的，以工单为驱动的交接原来是摩擦的一个重大来源。各种工单排成队列，静静地躺在那里，等待有人注意到它们，构建和测试结果无所事事，知道有人能够检查它们，人到人的通知也必须按顺序进行，这样整个过程才能继续。
考虑到亚马逊对自动化的专注和使用机器人来加速有形商品在合同执行中心之间的流动，在软件交付过程中我们依赖于手工的，人工驱动的各种进程来推动各种无形的比特码，这有点讽刺意味。
为了加速软件交付过程，我们构建了一个名为Pipelines的内部系统。该系统允许我们的各个团队将他们的发布过程的各个部分联系起来。这包括预生产环境中的源代码控制，构建，部署和测试，以及部署到生产中。不用说，该工具极大地减少了将特定的代码更改部署到生产所需的时间。
尽管更快的交付是该工具的主要驱动力，但是结果显示，我们也看到了一些其他的好处。通过确保每一项代码更改经受相同的质量把关，我们的团队更早地发现问题，生产质量更高的版本，减少了由于部署到生产中的错误代码导致的系统回退的数量。
现在，Pipelines在亚马逊被普遍地使用。各个团队使用它作为主要的仪表盘，来监控和控制软件版本。
伴随着CodePipeline在今天发布，现在你可以使用与我们的开发者相同的性能！
关于CodePipeline
CodePipeline是一项持续的软件交付业务。它允许你将发布软件所需的各个步骤进行建模，可视化和自动化。你可以定义，然后完全自定义代码从记录到构建，再到测试，最后到部署的过程中所需的所有步骤。
你的组织，像其他大多数组织一样，可能使用各种各种的工具（开放源代码工具或其他）作为构建过程的一部分。内置的集成工具，和那些可以从合作伙伴那里获取的工具，将会允许你在这一全新的，高度自动化，工作流驱动的世界中使用你已有的各种工具。你也可以将自己的源控制，构建，测试和部署工具连接到使用新的自定义动作API的CodePipeline。
实现发布过程的自动化将会使该过程更快捷，更一致。结果，你将可以更加频繁地将小的更改推入到生产中。你将可以在各种更改经过你的发布管道时使用CodePipeline仪表盘进行查看和控制。
快速导览
我将创建一个简单的两级管道。该管道使用一个版本化的S3桶和AWS CodeDeploy来发布一个示例应用。
我以创建一个新桶（jbarr-code）和启动版本化来开始创建过程：
我需要一个平台来部署代码，所以我打开了CodeDeploy Console，使用示例部署，将三个EC2实例投入到一个部署组中：
然后我打开CodePipeline Console，使用Deployment Walkthrough Wizard（部署演练向导）来创建我的部署资源。我将会将我们的管道命名为DeployMyCode：
现在我告诉CodePipeline到哪里去找代码。我将S3桶和对象名称（该对象包含我想部署的代码）引用为Source Provider：
作为另外一种选择，我也可以使用一个GitHub知识库作为我的Source Provider（代码源提供者）。
下一步是通过指定一个Build Provider（构建提供者）告诉CodePipeline如何构建我所需的代码。在本示例中，代码是一个脚本，可以按原样运行，所以我不需进行代码构建。
我也可以使用Jenkins作为构建提供者。
既然（在管道运行时）我们没有构建代码，下一步就是部署代码进行预部署测试。我安排使用几分钟前我刚刚设置的CodeDeploy配置（包括目标EC2实例）：
我需要在我的账户中创建一个IAM角色，赋予CodePipeline使用AWS资源的权限：
这步完成后，我就可以确认我的选择，创建我的管道了：
管道立刻开始运行：
我可以将鼠标停在“i”上来了解关于特定阶段配置的更多信息：
当我的代码更改，我将一个新的版本上传到S3（在本示例中）时，CodePipeline将会检测到这一更改，自动运行管道。我也可以点击Release change（发布更改）按钮实现同样的效果。
如果需要暂停两个阶段之间的管道，我可以通过点击Disable（并通过相应的解释）来实现管道暂停：
稍后我也可以通过一次点击操作重新启动该管道！
我也可以编辑我的管道。我可以更改一个既存管道，在管道末尾追加新的阶段，或在管道的其他点插入新的阶段：
例如，我可以添加一个测试步骤，然后（如果测试成功）添加一个部署到生产步骤。如果我增加了一个测试步骤，我也需要选择，然后连接到一个测试提供者：
连接步骤在测试提供者的网页上实现:
以上叙述的所有动作（或任何更多的动作）也可以通过AWS CLI执行。
CodePipeline集成
正如我前面提到的，CodePipeline可以使用既有的源控制，构建，测试和部署工具。下面是我目前所知道的CodePipeline集成的所有工具（如果我漏掉了任何一个，请给我留下评论，我将会更新我的帖子）：
源控制
- 亚马逊简单存储业务S3– 连接一个管道来发布S3桶中的源代码更改。
- GitHub–连接一个管道来发布一个公有或私有知识库中的源代码更改。
构建和持续集成
- Jenkins–在云中托管的Jenkins服务器中或本地部署的Jenkins服务器中运行构建流程。
- CloudBees–在CloudBees Jenkins平台上运行持续集成构建流程。
测试
- Apica–运行Apica LoadTest业务进行大容量负载测试。
- BlazeMeter-运行BlazeMeter业务进行大容量负载测试。
- Ghost Inspector–运行Ghost Inspector业务进行UI（用户界面）自动化测试。
- Runscope–运行Runscope业务进行API测试。
部署
- AWS CodeDeploy–部署到亚马逊EC2或任何使用CodeDeploy的服务器中。 to Amazon Elastic Compute Cloud (EC2) or any server using CodeDeploy
- AWS Elastic Beanstalk–部署到Elastic Beanstalk应用容器中。
- XebiaLabs–使用陈述式自动化和包含XL Deploy的预构建计划部署。
现在可用
CodePipeline现在已可用，你今天就可以在美国东部（北弗吉尼亚州）地区开始使用它，像往常一样，预计不久将扩展到其他地区。
每个月你只需为每一个活跃管道支付一美元（你所使用的第一个管道是免费的，这是AWS免费套餐的一部分）。 一个活跃管道是指在一个月内至少有一次代码更改其通过它进行的管道。
活动推荐： 8月4日AWS动手实验课堂系列：让你更省心的数据库大管家
原文链接： https://aws.amazon.com/cn/blogs/aws/now-available-aws-codepipeline/?sc_campaign=launch&sc_category=codepipeline&sc_channel=SM&sc_content=summit_launch&sc_detail=std&sc_medium=aws&sc_publisher=tw_go&adbsc=social_launches_20150709_48893086&adbid=619158766240448512&adbpl=tw&adbpr=66780587
（ 翻译/吕东梅 责编/王鑫贺 ）
订阅“AWS中文技术社区”微信公众号，实时掌握AWS技术及产品消息！
AWS中文技术社区为广大开发者提供了一个Amazon Web Service技术交流平台 ，推送AWS最新资讯、技术视频、技术文档、精彩技术博文等相关精彩内容，更有AWS社区专家与您直接沟通交流！快加入AWS中文技术社区，更快更好的了解AWS云计算技术。
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
