自動化ソフトウェアデリバリのためのパッケージマネージャーOrbsをCircleCIがローンチ

DevOpsプラットホームCircleCIが今日(米国時間11/7)、新しいパートナー事業を発表した。それによりこのプラットホームがオープンになり、サードパーティのツールを統合できるようになる。加えて同社は、パッケージマネージャーOrbsをローンチする。同社によるとそれは、“世界で初めての、ソフトウェアデリバリ自動化の構成のため専用のパッケージマネージャだ”。

今年初めに3100万ドルを調達したばかりのCircleCIは、競争の激しい継続的インテグレーションとデリバリの世界に、しっかりと根を下ろしつつある。今日発表されたローンチパートナーは、Cypress, JFrog, Pulumi, Sauce Labs, Sonatype, WhiteSourceなどだ。

そのパートナー事業はしかし、主にOrbsのためのステージになる。Orbsの考え方は、同社のユーザーに、彼らが好むCI/CDの構成を複数のチームやプロジェクトにわたって共有させ、彼らがそのコマンドやエグゼキュータ、ジョブなどを数行のコードで指定できるようにする。それは基本的には、チームがそのビルド/テスト/デプロイのワークフローをさらに自動化して、彼らのソフトウェアパイプラインを構成するためのベストプラクティスを共有する方法だ。新規ユーザーにとってOrbsは、大量の決まりきったコードを書かなくても容易に利用を開始できる。

CircleCIは、同社自身の証明されたOrbsと、パートナーが書いたそれらを提供する。現在あるOrbsは、Heroku用、Amazon S3用、CodeDeploy用など、また、お決まりのSlack通知Orbもある。全部で今日CircleCIがローンチするパッケージは、25ある。

“CircleCIのOrbsはCIの世界で、Dockerのコンテナ以後もっともエキサイティングなシステムだ”、こう語るCypressのエンジニアリング担当VP Gleb Bahmutovは、Orbsのアーリーアクセスカスタマーでコントリビューターでもある。“デベロッパーにとってOrbsは、これまでの‘ドキュメンテーションを読んでサンプルコードをコピペして30分いろいろやってやっとCIが終わる’というやり方に代わる、待望の工程改良だ”、と彼は言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GitHubからワークフロー自動化ツール、Actions登場――独自サービス提供の第一弾

最近Microsoft傘下に入ったGitHubは長らくオープンソースのコード共有と保管のためのサービスと考えられてきた。今日(米国時間10/16)、同社はGitHub Actionsを発表し、独自のサービスを開発、提供する路線の第一歩を踏み出した。 デベロッパーはActionsを利用することで、単にこのプラットフォームにコードを保存したり同僚と共有したりするだけでなく、実行することが可能になる。

これはAWSのライバルとなるようなクラウドというより、IFTTTに近いがもっとフレキシブルなサービスだ。Actionsはワークフローそのものを自動化して効率化を図りたいデベロッパーのニーズに応えるものだ。

これはGitHubの事業にとって重要な転換点だ。事実、GitHubのプラットフォーム責任者、Sam Lambertは私の取材に対して「GitHubの歴史上最大のシフトだ」と答えた。LambertはこのサービスをiOSのショートカットに例えた。ただしはるかに多機能で強力だという。「ショートカット・アプリと似ているが比べものにならないくらいフレキシブルなサービスがGitHubにホスティングされ、誰でもこのコンテナの中で自由にパーツを組み合わせて効率的な独自のワークフローが作成できるところを想像して欲しい」とLambertは述べた。

GitHubのユーザーはActionsを使って 継続的デリバリー・システムを構築できる。GitHubでは多くのユーザーがActionsによるパイプラインを作るだろうと期待している。実際ユーザーもこのプロジェクトについて聞いたときそう思ったに違いない。今日のGitHubの発表によれば、Actionsは「ソフトウェアのビルド、パッケージ、リリース、デプロイ、アップデートという一連の流れを大きく効率化する。またどんなプログラミング言語にも対応する。GitHub上で開発された場合でもと外部のシステムの場合でも、コードを自分では実行する必要はない」という。しかしこれはほんの手始めに過ぎない。Lambertはこう強調している。

継続的インテグレーションと継続的デリバリー(CI/CD)はActionsのユースケースのほんの一部だ。たしかにその面で役立つが、Actionsはそれ以上のものだ。これはDevOps全体に革命を起こすものだとと思う。なぜならActionsを用いることでこの種のものとして最高のアプリケーション、フレームワークのデプロイメントのサイクルを構築できるからだ。ActionsはGitHubでプロジェクトを共有する場合のデファクト・スタンダードになるだろう[…]オープンソースで実行していたすべてができる。DevOps方式の開発ワークフロー・エコシステムのすべての部分に適用できる。

つまり、誰かがリポジトリで「緊急」というタグを使った場合、Twilioを使ってメッセージを送信するという仕組みを作ることができる。レポジトリを検索する一行のコードを書いてgrepコマンドで実行することもできる。その他どんなコードでもいい。レポジトリ内のコードをActionに変換するためにはそのためのDockerfileを書いてGitHubで実行できるようにしさえすればいいからだ。 Lambertによれば「Dockerファイルさえあれば、Actionsでビルドし、実行し、ワークフローに組み込むことができる」という。Dockerfileを使いたくない場合はワークフローをビルドするためのビジュアル・エディタも用意される。

GitHubのプロダクト・エンジニアリングの責任者、Corey Wilkersonによれば、Actionsはすでに多くのGitHubレポジトリで利用されているという。 Actionsは現在はまだベータ版で限定的公開だが、GitHubには9600万のプロジェクトがあるのですぐにたいへんな数のActionsが生まれるだろう。【略】

将来は(Lambertはそうなることを期待しているが)多くのGitHubユーザーがActionsで作成したワークフローをGitHubのマーケットプレイスで販売することになるかもしれない。現在はまだ可能ではないものの、GitHubはこのオプションの可能性を真剣に検討している。Lambertは「エンタープライズ向けツールを開発、販売する(これはSales Forceがやっている)予定がないデベロッパーもActionsによるワークフローの販売でマネタイズができるようになるはずだ」と考えている。

GitHubはデベロッパーに対してActionsを順次公開していく予定だ。デベロッパーはこちらからActionsに登録できる。【略】

GitHubではまたLearning LabでデベロッパーがGitHubを学習するのを助けるための新しいコースを3種類リリースした。また大規模な企業向けのプライベートなLearning Labも用意されている。

GitHub Enterpriseのユーザーにとってもっとも興味深いのは、管理者が個々のプログラマーの公開プロフィールに開発したプロジェクトを表示できるようになったことかもしれない。デベロッパーのコミュニティーではGitHubが事実上、履歴書として機能していることを考えると、このオプションが与える影響は大きい。

その他の発表はセキュリティーの強化に関するものが中心だった。たとえばGitHub Security Advisory APIはコードをスキャンしデベロッパーが脆弱性を発見することを容易にする。またJavaと .NETのプロジェクトには新たな脆弱性のアラート機能も追加された。 【略】

原文へ

滑川海彦@Facebook Google+

GoogleのCI/CDプラットホームCloud Buildがコンテナイメージの脆弱性をスキャンする

Googleが今日(米国時間9/19)、同社のCD/CIプラットホームCloud Buildの重要なアップデートを発表した。それにより、このサービスを利用して構築されるすべてのコンテナイメージに対し脆弱性スキャンが行われる。Container Registryに対するその脆弱性スキャンはまだベータだが、現代的なDevOpsの実践手法を採用した企業に対し、彼らがデプロイするコンテナに確実に、既知の脆弱性がないようにすることがそのねらいだ。

Googleがいみじくも言うように、セキュリティプロトコルがつねに確実に実践されているようにするための唯一の方法は、その工程を自動化することだ。今回の場合では、Cloud Buildの新しいイメージはすべて、Cloud Buildがそのイメージを作ってそれをContainer Rgistryに保存するそのときに、自動的にスキャンされる。

このサービスは、セキュリティ関連の標準的ないくつかのデータベースを利用して脆弱性を見つける。現在、脆弱性を見つけることのできるのは、Ubuntu、Debian、そしてAlpineのパッケージだ。CentOSとRHELにも、近く対応する。

問題を見つけたらユーザーに通知するが、ユーザー企業が自動化のルールを決めて、自動的にアクションをさせることもできる。アクションへのメッセージングとアクションの実行にはそれぞれ、Google CloudのPub/Sub通知と、サーバーレスのCloud Functionsを用いる。ユーザーは、脆弱性の重度やCVSSのスコア、どのパッケージが危ないか、有効な対策の有無、などに関する詳細レポートを受け取る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

CI/CDを末端企業にも普及させたいArmoryはY Combinator出身で$10Mを調達

オープンソースのSpinnakerプロジェクトをベースとするCI/CDプラットホームArmoryが今日(米国時間8/22)、シリーズAのラウンドにより1000万ドルの資金を調達したことを発表した。このラウンドはCrosslink Capitalがリードし、Bain Capital Ventures, Javelin Venture Partners, Y Combinator, そしてRobin Vasanらが参加した。

ソフトウェア開発は、ここ数年で確かに変わった。間隔の長いアップデート・サイクルに代わり、継続的デリバリが主流になってきた。このコンセプトは今では、継続的インテグレーション/継続的デリバリ(continuous integration/continuous delivery)を表すCI/CDと呼ばれている。Armoryのプロダクトは、このタイプのソリューションをデプロイするときに伴う複雑性を、軽減しようとする。

同社を創業したときファウンダーたちは、CI/CD技術のバックエンドのベースとしてSpinnakerを使う、と決めた。それは、GoogleやNetflixなど業界の大物たちが支持しているプロジェクトだからだ。ArmoryのCEOで協同ファウンダーのDaniel R. Odioが、今回の資金調達を発表するブログ記事でこう述べている: “Spinnakerは大規模で本格的なマルチクラウドのデプロイを支えるスタンダードになるだろう。自分たちで新たに継続的デリバリのプラットホームを内製で構築する、そんな車輪の再発明を避けて、SpinnakerをArmoryプラットホームのコアにするという、大きな賭をした”。

同社によると、その賭は報われ、Spinnakerの同社バージョンはエンタープライズのソリューションで広くデプロイされている。同社の目標は、Fortune 2000社がソフトウェアのデプロイを今よりずっと速くできるようになることだ。そしてそのためには、CI/CDのアクセスと理解が欠かせない。

今企業は、どんな企業でもソフトウェア企業になりつつあるから、どの企業もこれまでとは異質な部分を抱え込むことになる。GoogleやNetflixのような超大物は、最先端の方法により、ソフトウェアを驚異的なスピードでデプロイする方法を経験から学び構築しているが、製品の製造技術=ソフトウェア開発技術ではない、そこらのふつうの企業は、ソフトウェア技術者もそんなに多くないから、Googleなどに追随することは難しい。

その空隙を補ってくれるのが、Armoryのような企業だ。同社は、オープンソースの技術を核として、その複雑性を包み隠すパッケージにより、高度なソフトウェアデプロイ技術を持たない普通の企業でもCI/CDを導入できるようにする。

中でもとくに同社が強調するマルチクラウドでクラウドネイティブなソフトウェア開発方式は、ユーザーのアプリケーションやインフラストラクチャを、オンプレミスも含む複数のクラウドに分散可能にする。そのようなデプロイ技術の重要な部分が、継続的デプロイを管理する技術だ。

Armoryは2016年にローンチし、ベイエリアに拠を構える。これまで1400万ドルを調達したが、そのうちの400万ドルのシードラウンドは昨年行った。同社はY Combinator 2017冬季の卒業生であり、Y Combinatorは今回の投資に参加している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ShippableとARMとPacketがパートナーしてARMベースのサーバーにCI/CDプラットホームを提供

継続的インテグレーションとデリバリー(CI/CD)の市場は、その大半がハイエンドのx86サーバーにフォーカスしているが、しかしARMベースのサーバーの出現により、ARMサーバーの上でネイティブに動くソリューションへの需要も芽生えてきた。そしてその気運に乗ったCI/CDプラットホームShippableは今日(米国時間7/9)、ベアメタルのホスティングプラットホームPacketおよびARMとパートナーして、まさにそのようなソリューションを提供しようとしている。

そのパートナーたちは、ARMベースのサーバーの採用が増えているのだから、デベロッパーはそれらをネイティブにサポートするCI/CDプラットホームが必要だ、と主張する。“正しいインフラストラクチャの上でテストできることが、楽しめるビルドプロセスと苦痛なプロセスをわける境界だ。エッジやIoTなど今急成長中の分野につきものの、多様なハードウェア環境ではとくにそう言える”、とPacketのCEO Zac Smithは言う。“Shippableは最初からARMをサポートしているので、その速いビルドとシンプルなワークフローの組み合わせは、他に類がないほど強力だ”。

Packetは現在、比較的強力なARMベースのマシンを1時間$0.50(50セント)で提供しているが、競合他社も多くて、たとえばScalewayはメニューがもっと豊富だ。

当然ながらShippableはPacketのARMマシン上に同社がホストするCI/CDプラットホームを提供し、その上でデベロッパーは32ビットおよび64ビットのアプリケーションを構築できる。オープンソースのプロジェクトを動かしているなら、そのワークフローのビルドとテストに無料でアクセスできる。

このようなコラボレーションがここでも再度強調しているのは、Packetのようなセカンドティアの(== あまりメジャーでない)クラウドプロバイダーと、彼らの周辺にあるデベロッパーツールのエコシステムは、パートナーシップを武器としてAWS, Google, Microsoftのようなハイパースケールなクラウドベンダーに対抗する、というパターンだ。たとえばPacketは最近、このほかにPlatform 9やBackblazeなどともパートナーシップを組んだ。今後このような動きが、さらに多くなると予想される。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

2017年誕生のKubernetesに特化したCI/CDプラットホームCodefreshが早くもシリーズBで$8Mを調達

Kubernetesのコンテナエコシステムのための継続的インテグレーションとデリバリーのプラットホームCodefreshが今日(米国時間6/27)、MicrosoftのベンチャーファンドM12がリードするシリーズBのラウンドで800万ドルを調達したことを発表した。Viola Ventures, Hillsven, そしてCEIFがこのラウンドに参加し、これで同社の調達総額は1510万ドルになった。

このところ、CI/CDプラットホームは毎日どこかで生まれているようだが、CodefreshはKubernetesへの特化で自己を差別化している。Kubernetesは今や必須かつデファクトスタンダードのコンテナオーケストレーションサービスで、その採用は急速に増えている。Codefreshがやることは、Kubernetesへのアプリケーションのデプロイを助けることによって、“開発時間を最大で24倍はやくする”ことだ。それはあまりにも楽観的な数字だが、Kubernetesを使うアプリケーションの開発にCI/CDが加われば、開発とデプロイの工程がスピードアップすることは確かだろう。

Codefreshの協同ファウンダーでCEOのRaziel Tabibは語る: “Kubernetesの採用が急激に増えているから、ツールチェーンがそれに対応していない。M12は、そのことをよく知っている。今回得られた資金により、弊社のロードマップを加速し、顧客ベースを拡大したい”。

Codefreshのプラットホームがデビューしたのは2017年で、同社によると現在のユーザーは約2万社だ。その中には、Giphyなどもいる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

OpenStackがオープンソースのCI/CDプラットホームZuulを切り離して独立化

OpenStackほど複雑なオープンソースプロジェクトはほかにないと思われるが、これは要するに、AmazonのAWSのような総合的なクラウドコンピューティング環境を、企業が自分のデータセンターの(主としてプライベートな)インフラストラクチャとして装備するためのシステムだ。それを構成するさまざまなサブシステムを作るためにチームは、独自のDevOpsツールを作らざるをえなかった。2012年には、その一環として、オープンソースの継続的インテグレーションとデリバリ(CI/CD)プラットホームZuulを作った。そしてこのほど、Zulu v3のリリースを契機に、ZuluをOpenStackから切り離して独立のプロジェクトにした。でもOpenStackのエコシステムを去るわけではなく、依然としてそれは、OpenStack Foundationがホストするツールだ。

構造をざっと展望すると、OpenStack Foundationは一種の母体的組織であり、その傘下のメインプロジェクトとしてOpenStack本体のほかに、昨年おそく登場したKata Containersと、今回のZuulがある、という構造になる。すなわちOSFは近年、本体OpenStackのほかに、関連のインフラストラクチャプロジェクトも揃えよう、としているのだ。

Zuulはデベロッパーたちに、プロジェクトに新たな変更を加えようとするときの、コードのマージ、ビルド、そしてテストの工程を自動化するシステムを提供する。サポートする開発プラットホームはかなり幅広くて、GitHubや、コードレビューとプロジェクト管理のツールGerritなどもサポートしている。

Zuulの現在のコントリビューターは、BMW, GitHub, GoDaddy, Huawei, Red Hat, そしてSUSEだ。BMWのソフトウェアエンジニアTobias Henkelは語る: “ソフトウェアプロジェクトがCD/CIを幅広く採用することは、高品質なソフトウェアをタイムリーにデリバリするための基盤だ。それにより、個々のコミットチェックからフルリリースに至るまでの、開発サイクルの重要な部分を、すべて自動化できる。弊社BMWのCI/CDチームは、Zuulコミュニティの一員であることを誇りとし、オープンソースのZuulプロジェクトの積極的なコントリビューターであり続けたい”。

Zuulがスピンオフして独立した今の時期は、CI/CDに関して選択肢がとても多くなっている。GoogleとNetflixはオープンソースのSpinnakerで、Zuulと同様の機能を提供しようとしているし、またJenkinsとその類似プロジェクトたちも依然として強い。これらに対してZuulは、大規模で複雑な開発プロジェクトをうまく扱えるmulti-repo gatingマルチリポジトリ・ゲーティング)機能の有利性を強調している。

今カナダのバンクーバーで、これらのオープンソースプロジェクトの代表者たちによるOpenDevカンファレンスが行われており、そこでOpenStack Summitも併催されているので、数日〜数週間後にはこれらのプロジェクトすべてに関するより詳しい情報が出てくることだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa