インタビュー多くのクラウド企業が 4 つのナインの稼働率を目標としている中、GitLab では今日 4 つのナインを達成しました。ソース シャックがThe Registerとのチャットでバージョン 11.11 のリリースを祝ったのです。
GitLabはソースコード管理、そして最近ではCI/CDツールで知られています。Kubeconとタイミングを合わせ、GitLabはオーケストレーション技術に特化したリリースを発表しました。
GitLab のセルフマネージド版 (オンプレミスまたはパブリック クラウドで実行) のユーザーは、インスタンス レベルでクラスターをプロビジョニングできるようになりました。これにより、インスタンス内のすべてのプロジェクトがデプロイメントにクラスターを利用できるようになります。
Kubernetes の統合は Kubecon で大好評を博しましたが、Windows 上の Docker コンテナー用の GitLab Runner に新しいエグゼキューターが登場したことも少なくとも同じくらい役立ち、シェル エグゼキューターを使用して操作を実行するという安っぽい慣習に終止符が打たれました。
Windows 用の Docker コンテナーを直接使用できるようになることで、Microsoft プラットフォームのファンにとっては作業が簡素化され、Windows ユーザーにとってパイプライン オーケストレーションの選択肢が広がると同社は期待しています。
なぜなら、GitLab は最近 CI に重点を置いているからです。
GitLab のエンジニアリング マネージャーである Marin Jankovski 氏は、Windows の機能を「驚くべきもの」と評し、Runner を「任意のマシンにセットアップして、任意の種類のコードを実行できるバイナリ」と定義しました。
よかったです。ただし、Windows で作業していた場合は残念でした。
Jankovski 氏はさらにこう続けた。「Windows ではそのバイナリを実行できませんでしたが、ようやくそれが可能になりました。つまり、Windows 環境に依存するすべてのプロジェクトで、手間をかけずに DevOps CI を使用できるようになりました。」
正直なところ、DevOpsパイプラインに最も必要なのは余計な手間ではありません。多くのパイプラインは、ダクトテープ、唾、そして祈りといったコンピューターの技術で繋ぎ止められている傾向にあります。
リリース11.11では、SlackとMattermostのデプロイメントイベントと、リリースページへのゲストアクセスが追加されました。これにより、ゲストはソースコードを入手することなく、公開されているものをすべてダウンロードできます。その他の調整としては、頻繁に使用されるDockerイメージ用のキャッシュプロキシや、毎月のアップデートでコミュニティから提供される様々な変更点が含まれます。
また、GitLab には 1 つのコードベースがあるため、そのアップデートは、SaaS スタイルで GitLab に管理を任せている顧客だけでなく、自己管理している顧客にも提供されます。
同社は過去 3 つのリリースの修正 (セキュリティ問題の場合はさらに多く) をバックポートする予定ですが、顧客は同社が設定したペースを維持するものと予想されます。
3 か月以上前のバージョンを使用している場合、GitLab はサポートしようとしますが、サポートの先頭に「アップグレードはどうですか?」と表示されます。
ヤンコフスキー氏はこう付け加えた。「彼らは望むならコードにパッチを当てることができる。オープンソースだから、何でもできるのだ…」
一体何が問題になるのでしょうか?
ランサムウェア？聞いたことありますよね
Git365、チームのためのGit、QuatermassとGit Pit。GitHubはもう通用しない。Microsoftがそれを実現した。
続きを読む
GitLabは、競合他社と同様に、最近のリポジトリランサムウェアの流行を非常に深刻に受け止めています。Linux Foundation理事であり、アライアンス担当副社長のブランドン・ユング氏は、同社は「認証情報とシークレットの管理、そしてコードのスキャンを徹底し、お客様にとって安全性の高いデフォルトの設定を実現する方法に常に取り組んでいく」と述べました。
しかし、彼とヤンコフスキーの両者が認めているように、顧客が本当に望めば、「愚かなことをすることもできる」のだ。
厳しいが公平だ。
DevOpsのドッグフーディング
同社の起源はソース管理ですが、サンフランシスコを拠点とする企業（最近、投資家から多額の資金を調達し、評価額が 10 億ドルに達しました）は、DevOps 分野に参入するという目標を掲げており、Jung 氏は謙虚にその目標は達成済みだと考えています。「CI は大きな焦点です。そして、すべてをまとめて出荷しているので、非常に多くのお客様にとって非常に簡単な勝利となっています。」
同社の「自社のドッグフード」を積極的に活用する習慣が功を奏している。ヤンコフスキー氏はこう説明する。「皆さんが今目にしているものはすべて、私たちがこうした問題に直面し、まず自分たちで解決策を提示し、自社のユースケースで試行錯誤した結果です。そして今、お客様が同じ道を歩むとき、それはスムーズで、とても簡単に進むのです。」
GitLabは便利なツールです。なぜなら、GitLabだけが選択肢ではないからです。顧客はDevOpsベンダーの選択肢に事欠きません。どのベンダーも、コードを書く代わりに壊れたパイプラインを修正することに疲れ果てた開発者のために、包括的なエンドツーエンドソリューションを提供するという、同じ聖杯のような主張をしています。しかし、ソースシャックには、リポジトリという形で既に参入の足掛かりがあるという利点があります。
CI の今後の展開として、Jung 氏は、パイプライン周辺のセキュリティにリソースを投入し、動的コード分析にも追加作業を行う予定だと述べました。
ヤンコフスキー氏は、チームが本当に望んでいたのは、顧客がJenkinsやJiraのようなツールを優先してGitLabの組み込みCI機能を無効にするのをやめることだったと、物憂げに付け加えた。しかし、ユーザーが古いDevOpsのツールを使い続けるのであれば、GitLabは顧客の「古いCI」の中で「最新のGitソースコード管理」を提供できればそれで満足だ、と付け加えた。
GitHub の GitLab
競争について、ユング氏とヤンコフスキー氏は予想通り率直に語った。結局のところ、GitLabはGitHubを犠牲にしてちょっとした遊びをしており、MicrosoftがGitLabへの移行を発表した時点で、リポジトリがGitLabのプラットフォームに移行する急増を強調していたのだ。
2人は、Azure に GitHub の認証情報が追加されたことで、待望の Git365 のブランド変更が行われるかもしれないと冗談を言った。
しかし、ユング氏はオープンソースの方向性について懸念を示し、「どんどん新しいものが出てくるのを見ると、まるでカエルを茹でるような感じだ」と述べ、マイクロソフトの管理下でのGitHubの進化については「少しずつ追加される部分を見ると、ああ、これはセキュリティが強化される。これはまた別の部分だ…」と述べている。
今月初めのThe Regとのインタビューで、マイクロソフトのゲイブ・モンロイ氏は同社の影響力に対する懸念に対し、「我々の行動によって人々が我々を判断できることを望む」とコメントした。
一方、マイクロソフトは、開発者がGitHubから離脱した場合、GitHubに支払った数十億ドルをはるかに上回る損失を被ることを痛感していると述べています。EUの時に辛辣な監視機関でさえ、事態が悪化すれば、開発者はどこかクールな場所へ飛び移ることができると述べています。
そして、長年にわたるいくつかの印象的な失敗にもかかわらず、GitLab とその CI フォーカスは彼らを歓迎します。®
