持续交付工具领域：DevOps越出SaaS界线

作者：佚名 2016-08-09 09:12:55

云计算

SaaS 主要作为软件即服务（SaaS）提供的DevOps工具在本月开始向用户提供了新的部署方式，视图吸引开始流水线化开发流程、但可能并不会将服务部署到公有云上的大型企业。

 　　企业DevOps正在评估持续交付工具的新版本，该工具可以部署在防火墙后，在某些情况下，这么做能够提升安全性，并带来更好的性能。

　　主要作为软件即服务(SaaS)提供的DevOps工具在本月开始向用户提供了新的部署方式，视图吸引开始流水线化开发流程、但可能并不会将服务部署到公有云上的大型企业。Shippable、CloudBees 和 CircleCI同时在本月开始尝试超越SaaS;CloudBees已经有了可以在本地部署的企业版本，但是现在提供了新的私有云SaaS版本。

[[169666]]

　　目前在其本地防火墙后使用Atlassian Bamboo持续交付工具的传统企业正在研究基于Jenkins的搭建，使用CloudBees新的私有云SaaS版本，该产品拥有自扩展和自修复的特性，让DevOps支持者可以在本地部署，并且将其作为服务交付给企业内的开发人员。

　　“两个世界里***”的方案吸引了Mario Cruz，他是Watsco Ventures的主管，Watsco Ventures是HVAC经销商。Curz在之前的工作里使用CloudBees，并且尝试将其引入Watsco的内部来满足安全需求，同时让持续交付流程更加容易。

　　CloudBees所基于的Jenkins的最为吸引人之处，在于其活跃且受欢迎的开源社区，Cruz说。

　　“如果想要用它来做一些之前没有做过的事情，相应的解决方案很可能已经存在了，这和Bamboo不一样，它的所有工作都只能依靠Atlassian，”Cruz说。

　　CloudBees的私有云SaaS版本很有希望能够通过运行本地Jenkins服务器来缓解一些让企业头疼的事情，Curz说。

　　另一家拥有大量使用Ruby构建的本地API的公司对Shippable的***版本也很感兴趣，该版本包括一个适配器，能够在私有云上部署软件，并且无需编写复杂的基础架构代码，同时还能改进性能。

　　Packet，总部位于纽约的一家纯物理托管服务器供应商，每个版本都有带有很多API的很多包。完成这么多包的测试工作量很大;有时候开发人员需要等待20到25分钟，基于SaaS的Shippable测试才能运行完成，Aaron Welch说，他是公司的联合创始人及资深副总裁。“即使你每天只需要做一次，但是就会让整个团队处于等待状态。之后如果构建失败，他们就不得不再次等待，”他说。

　　这个新版本让Packet能够在其海量纯物理服务器上部署软件，帮助API构建时间下降到5或6分钟——这有“很大的不同”，他说。“如果过去的一年里比较一下等待25分钟和5分钟的区别，就能意识到我们之前浪费了多少时间，现在通过使用自己托管的版本能够节约多少时间，”Welch说。

　　有安全意识的企业还对能够部署在本地私有云或者云供应商基础架构的持续集成和持续交付工具感兴趣，企业IT正是目标用户群体，Baron Schwartz说，他是VividCortex，一家位于夏洛兹维尔的数据库监控SaaS供应商的创始人及CEO。他也正在思考将自己的产品转变为本地软件，来吸引大型企业客户。

　　“大家每年花费上千或者数千美元租赁东西，但是当达到6或者7千时，你得到得反而更少，”Schwartz说。

　　VividCortex还坚持为其DevOps工具链的持续交付部分提供用户可部署的软件，目前这部分在搭建了Jenkins的Amazon Virtual Private Cloud上完成。但是这样可能并不灵活，Schwartz也承认这一点。

　　“我不认为所有人都最喜欢Jenkins系统，”Schwartz说。“它的确备受关注，并且支撑着我们基础架构相关的其他部分。”比如，大概有一半的时间里，是Jenkins服务器导致VividCortex环境的磁盘使用报警，或者某个服务器使用了过高百分比CPU。

　　但是，Jenkins高度可自定义，并且可以在VividCortex的VPC里运行，它已经是该公司的DevOps工具链上不可缺少的部分。CircleCI Enterprise还可以修改为使用shell脚本，但是Schwartz认为需要更多的研究来决定这是不是完整的替代方案。