開発チームと運用チームの一貫したワークフローを構築する方法

GitHubが最近発表した「2022 State of the Octoverse」レポートにおいて、HashiCorp Configuration Language（HCL）がGitHubで最も成長したプログラミング言語となりました。HashiCorpは、クラウドコンピューティングのためのInfrastructure as Code (IaC) 自動化のリーディングプロバイダーです。HCLは、Terraformや Vaultなどのツールと共に使用されるHashiCorpの設定言語で、マルチクラウドやオンプレミス環境において、人間が読みやすい設定ファイルでIaC機能を提供することができます。 HCLの成長は、インフラ、運用、開発者の世界を一つにすることの重要性を示しています。これは常にDevOpsの目標でした。しかし、現実には、多くの企業でこれらの世界がサイロ化したままになっています。この記事では、開発チームと運用チーム、そしてセキュリティ、ガバナンス、ネットワーク・チームを結びつけるビジネスと文化の影響について見ていきます。そして、GitHubとHashiCorpがCI/CDパイプライン全体を通して一貫したワークフローとガードレールをどのように実現できるかを探ります。従来の運用（Ops）の世界 HashiCorpの共同創業者であるArmon Dadgar氏は、従来のOpsの世界を「木」に例えて説明しています。トランクには、物事を成し遂げるために企業で必要な、共有され一貫性のあるサービスがすべて含まれています。セキュリティ要件、Active Directory、ネットワーク構成などを考えてみてください。ブランチは、企業内のさまざまなビジネスラインを表し、社内または社外にサービスや製品を提供します。葉は、ソフトウェアやサービスが展開されるさまざまな環境と技術を表します。クラウド、オンプレミス、コンテナ環境などです。多くの企業では、これらの異なるビジネス領域間のコミュニケーション・チャネルやプロセスが煩雑で、コストがかかる場合があります。インフラやアーキテクチャに大きな変更があった場合、通常、複数のチケットが複数のチームに提出され、企業内のさまざまな部署でレビューと承認が行われます。組織を保護するために、変更諮問委員会が一般的に使用されます。通常、文書化が完了しない限り、変更を進めることはできません。一般的に、将来の監査に必要な一連のガバナンスログと監査可能な成果物が存在します。もし、チームが最適化された自動化されたワークフローを持ち、それを使って納期を早め、安全なガードレールのセットで仕事を終わらせることができるようになったら、企業にとってより有益ではないでしょうか？これは、時間とコストの大幅な節約につながり、ビジネス価値の向上につながる可能性があります。最近のForresterのレポートでは、GitHubを使うことで3年間で433%のROIを達成したという結果が出ています。もちろん、時間の節約や効率の向上は言うまでもなく、一貫性と作業の合理化によってもたらされるその他の質的なメリットもあります。あなたの製品やサービスは、遅々として進まない、手作業でエラーが起こりやすいプロセスではなく、セキュリティとガバナンスが組み込まれた最適化された経路でデプロイされることになるでしょう。これこそ、DevOps、GitOps、Cloud Nativeの夢ではないでしょうか？ IaCの導入別の例えを使いましょう。IaCは、ソフトウェアやサービスをホストするリソース（サーバー、データベース、ネットワークコンポーネント、PaaSサービスなど）の設計図だと考えてください。病院と学校を設計する場合、両シナリオで同じ全体的な設計図を使用することはないでしょう。なぜなら、両シナリオはまったく異なる目的を持ち、要件も大きく異なるからです。しかし、2つの設計にまたがって再利用できる構成要素や基礎があるはずです。 HCLのようなIaCソリューションでは、ソフトウェア開発でメソッド、モジュール、パッケージライブラリを再利用するのと同様に、これらのビルディングブロックを定義して再利用することができます。IaCであるため、アプリケーションでコラボレーションやデプロイを行う際に使用するのと同じ推奨プラクティスをインフラに採用することができます。結局のところ、DevOpsの方法論を採用するチームは、生産性、クラウド対応のスケーラビリティ、コラボレーション、およびセキュリティが向上することが分かっているのです。より良いデリバリー方法このような背景から、インフラストラクチャをコード化することで得られる具体的なメリットと、それが従来の運用文化の変革にどのように役立つかを探ってみましょう。リポジトリにコードを保存するまずは、最も低いところにある果実から始めましょう。IaCであれば、GitHubなどのソースコード・リポジトリにインフラストラクチャやアーキテクチャ・パターンを保存することができます。これにより、完全なバージョン履歴を持つ単一のソース・オブ・トゥルースを手に入れることができる。これにより、必要に応じて変更をロールバックしたり、履歴から特定のバージョンの真実をデプロイしたりすることが容易にできるようになります。企業内のチームは、Git リポジトリ内の個別のブランチでコラボレーションを行うことができます。ブランチを使うことで、チームや個人は「自分のスペース」で生産的になり、「本番」の真実のソース（通常はメインブランチ）から離れて、他のチームの進行中の作業に悪影響を与えることを心配する必要がなくなります。前節で述べた再利用可能なビルディングブロックであるTerraformモジュールも、Gitリポジトリに保存されバージョン管理されています。そこからTerraform Cloudのプライベートレジストリにインポートすることで、全チームが簡単にモジュールを発見できるようになります。GitHubで新しいリリースバージョンのタグが付けられると、レジストリにも自動的に更新されます。早期かつ頻繁にコラボレーションする上で説明したように、チームは現在の状態に影響を与えないように、別々のブランチで変更を加えることができます。しかし、その変更を本番環境のコードベースに反映させたい場合はどうすればいいのでしょうか。もしあなたが Git に慣れていないのなら、プルリクエストという言葉を聞いたことがないかもしれません。その名のとおり、あるブランチから別のブランチに変更を「引き込む」ことができます。 GitHub のプルリクエストは、チーム内の他のユーザーとコラボレーションするためのすばらしい方法です。ピアレビューを受けることで、フィードバックを自分の作業に反映させることができます。プルリクエストのプロセスは、チーム全体のコラボレーションを促進するために意図的に非常にソーシャルになっています。 GitHub では、ブランチ保護ルールを設定してメインブランチへの直接の変更を不可とすることもできます。そうすれば、すべてのユーザーがコードを実運用に移すにはプルリクエストを経由しなければならなくなります。ブランチ保護ルールには、最低限必要なレビュアーの人数を指定することもできます。ヒント:GitHub のCODEOWNERS ファイルという特殊なファイルを使えば、編集中のファイルに基づいてプルリクエストにレビュアーを自動的に追加することができます。例えば、すべてのHCLファイルは、コアインフラストラクチャチームによるレビューが必要かもしれません。あるいは、勘定系システムのIaC設定には、コンプライアンスチームによるレビューが必要かもしれません。通常、特定の周期で行われる変更諮問委員会とは異なり、プルリクエストはコードを本番環境に導入するためのプロセスの自然な一部となります。また、意思決定や議論の質も向上します。外部システムで推奨される「イエス/ノー」の決定ではなく、プルリクエストで直接コンテキストと推奨を確認することができます。プロビジョニングプロセスではコラボレーションも重要です。GitHubとTerraform Cloudの統合により、これらのプロセスを複数のチーム間でスケールさせることができます。Terraform Cloud は Terraform の状態を安全に保存し、GitHub リポジトリと直接統合することで、プルリクエストとマージのライフサイクルをターンキーで体験できるようなワークフロー機能を提供します。自動化された品質レビューをプロセスに取り入れる前節の続きですが、プルリクエストでは、提案された変更の品質を自動的にチェックすることもできます。ソフトウェアでは、アプリケーションが正しくコンパイルされているか、ユニットテストは合格しているか、セキュリティの脆弱性はないかなどをチェックするのが一般的です。 IaCの観点からは、同様の自動チェックを我々のプロセスに取り入れることができます。GitHub のステータスチェックを使えば、特定の条件を満たしているかどうかを明確に把握することができます。 GitHub Actions は、GitHub のプルリクエストでこうした自動チェックを実行するためによく使われるものです。IaCの品質を判断するために、以下のようなチェックを入れることができます。コードが構文的に正しいかどうかを検証する（例えばTerraform validate）。コードが特定の標準に従っていることを確認するためのLinting（例えば、TFLintや Terraform format）。静的コード解析により、「設計時」にインフラストラクチャの設定ミスを特定します (たとえば、tfsecやterrascan など)。関連するユニットテストまたは統合テスト（Terratest などのツールを使用）。インフラストラクチャを「スモークテスト」環境にデプロイし、インフラストラクチャの構成が（既知のパラメータセットと共に）望ましい状態にデプロイされることを検証します。 Terraform on GitHubを使い始めるのは簡単です。TerraformのバージョンはLinuxベースのGitHubでホストされたランナーにインストールされていますし、HashiCorpには公式のGitHub Actionがあり、指定したTerraformバージョンを使ってランナーにTerraformをセットアップしてくれます。

新しいデータセットでオープンソースに関する政府の政策を測定する

Published at February 23, 2023
Category: Open Source,Policy,GitHub Policy,open source
Author: Mike Linksvayer

Summary

GitHub Policyは、ソフトウェアがどのように構築され、誰がそれを構築するのかに影響を与える政策の開発に情報を提供するための研究とデータを支援することを誇りにしています。 GitHub Policyは、以下のような研究を支援しています。

世界中の政策立案者は、ソフトウェアがどのように構築され、誰が構築するのかに影響を与える政策を開発しています。

世界中の政策立案者は、ソフトウェアがどのように構築され、誰がそれを構築するのかに影響を与える政策を策定しています。GitHub Policyは、開発者とソフトウェアイノベーションの利益を代表するために活動しています。その1つの方法として、政策立案に役立つ研究やデータをサポートします。私たちは、Center for Strategic and International Studies (CSIS)がオープンソースソフトウェアのデータセットに関する政府政策を更新することを支援できることを誇りに思っています。

このデータセットは、オープンソースソフトウェアに関連する世界中の公共政策のカタログで、1999年まで遡ることができます。CSIS はこのデータセットを作成し、数年にわたり更新してきましたが、2010 年に 7 回目となる最新のデータセットを作成しました。長年にわたり、このデータセットは、開発者や研究者にリソースを提供してきました。例えば、以前のバージョンは、世界中のスタートアップ企業の設立にGitHubのアクティビティがどのように貢献しているかを示す研究に使用されました。この最新版でコミュニティがどのような成果を挙げるか、私たちは楽しみにしています。

このデータセットが最初に公開されて以来、各国政府は、「アップストリームに貢献する」ことで、企業と同様に、自分たちが依存するソフトウェアに対してより高い安全性と影響力を得られることを学びつつあり、政府が利用できる貢献ツールの幅も広がってきています。ドイツの Sovereign Tech Fundは、重要なオープンソースプロジェクトのメンテナを政府が支援するエキサイティングな一例です。サイバーセキュリティ、イノベーション、およびサービス提供においてオープンソースが果たす役割から、政府は、より広範な技術政策を策定する際にオープンソースへの影響を考慮することが不可欠となります。このような動きを考えると、世界中のオープンソースに関する政府の政策について、優れたデータを入手することが、これまで以上に急務となっています。

先月、GitHubの最高法務責任者であるシェリー・マッキンリーは、CSISで行われたデータセットの立ち上げを記念したパネルに、オープンテクノロジー基金のローラ・カニンガム、米国サイバーセキュリティおよびインフラセキュリティ局のアラン・フリードマン、ハーバードビジネススクールのフランク・ネーグル、そしてデータセットを共同執筆したユージニア・ロストリと共に参加しました。ディスカッションでは、サイバーセキュリティにおけるオープンソースへの注目の高まり、オープンソースの影響力の測定、オープンソースソフトウェアを保守・使用するコミュニティを支援する取り組みの重要性などが強調されました。

CSIS と共に、コミュニティがこのデータセットにどのように貢献し、構築していくかを見るのが楽しみです。あなたの国では、オープンソースについて言及している他の政策に出会いましたか？実装を考慮したデータセットの拡張に興味があり、最初の調査結果を提供したいとお考えですか？他のデータセットと相互参照するためのアイディアがありますか？このデータセットを利用した研究のアイディアがありますか？Issues またはプルリクエストを発行してください

Source

Measuring government policy on open source with a new dataset

Policymakers around the world are developing policies that impact how software gets built and who gets to build it. GitHub Policy works to represent the interests of developers and software innovation. One way we do so is to support research and data to inform policy development. We’re proud to …

GitHub Blog | 非公式日本語

すべての公開リポジトリでシークレットスキャンアラートが無料で利用可能になりました！

意外と知らない、GitHub Codespacesでできる10のこと！

開発チームと運用チームの一貫したワークフローを構築する方法

アジリティを低下させることなく、コンプライアンスのニーズに応える3つの方法