JFrogディベロッパーアドボケイトのよこなです🐸
「アーティファクト」って聞いたことありますか？
日本だと、そんなに馴染みがない方や、意味は分かるけど常用はしないという方も多いのではないでしょうか？と言っても日本以外での浸透具合を知っているわけではないのですが、少なくともウィキペディアに英語や中国語のページはあるのに対し、日本語版はありません*1。
JFrogでは、DevOpsを語るときにしばしば「アーティファクトの管理が大事ですよ」という話をします。
今回はその前提知識とも言える、そもそもアーティファクトとは何なのかについて書いていきます。
ソフトウェア開発において、アーティファクトとは「ソフトウェアを作る過程で生み出されたもの」を指します。
クラス図、ソースコード、デザインファイル、テストのエビデンス、ログファイルなどなど。広義では、あれもこれもアーティファクトです。
広義のアーティファクト
一方、話のスコープが狭まるとアーティファクトが指すものも変わってきます。
例えば特定の環境 (開発環境、ステージング環境、本番環境など) に限った話をしているときはその環境で作られた成果物を指しているかもしれません。コードをGitリポジトリにプッシュしてからデプロイまで実行するCIについて話しているならば、プッシュ前にローカルでできたファイルなどは対象から外れることもあるでしょう。また、npmやgem, Mavenなどパッケージマネージャーが話題の中心なら、ビルドした結果のバイナリファイルをアーティファクトと呼ぶこともあります。
冒頭で触れたJFrogが管理しましょうねと言っているアーティファクトは、多くの場合パッケージマネージャーやDockerなどを用いてビルドを行った際にできるファイルを指しています。いわゆるバイナリファイルですね。
JFrogに限らず、DevOpsを促進するようなツールや会社のサイトを訪れると同様に「アーティファクト (英語サイトではartifact) 」という言葉が使われています*2。
本記事では以下、この意味でアーティファクトという言葉を用います。
DevOpsで登場するアーティファクト
同じものを示す様々な表現に要注意
日本語でアーティファクトのことを表現する方法は結構たくさんあります。「バイナリ」、「成果物」、「ビルド成果物」・・・。口頭だともっとくだけて「ツール使って固めたやつ」、「パッケージマネージャーが吐き出したもの」みたいな言い方でも通じることがあります(よね？)。
例えばソースコードの管理あたりと比べても、アーティファクトの管理はまだまだ定着していないし語られる頻度も少ないため、皆が標準的に使う言葉が決まっていないのかもしれませんね。
ちょっとだけアーティファクト自体の定義を一歩踏み出た話をします。アーティファクトとセットで大事な情報を持つ「メタデータ」についてです。
アーティファクトは多くの場合バイナリファイルなので、ほとんどの人間はそのまま読むことができません。そのため、そのバイナリの特徴をメタデータとして付与します。ビルドした人の名前、ビルドしたサービスの名前、リリースバージョン、ビルド実行時刻、ビルド実行環境などを別ファイルやツールにより分かるようにしておくのです。
アーティファクトはリリース時にある環境から別の環境へ移したり、エンジニア間でシェアしたりすることがあるので、メタデータを使って見分けることで、作業対象を誤らずに見分けることができます。
なお、複数の技術やパッケージマネージャーを使っている場合、メタデータの付与方法や形式も異なるので、「どんなアーティファクトであっても必ず欲しい情報」を同じ方法で取得できるとは限りません。そこで、アーティファクトを統合的に管理する「バイナリ・リポジトリマネージャー」を用いると、あらゆるものに対して一貫性のある管理を行うことができます*3。
アーティファクトについて完全マスターしたところで、今回はここまでです！正直な話、私が数ヶ月前に「アーティファクトって日本語で何だ？」と疑問に思ったものの日本語だとあまり資料がなく困ったので書いてみました。「アーティファクトとは」「アーティファクト 何」なんて検索した方がここにたどり着いて疑問を解消してくだされば幸いです😏
アーティファクトの管理についてはまたブログ書きます！ツールの使い方とかも紹介する予定です。
あとお得情報なのですが、4月30日(木)に実践的なアーティファクト管理についてウェビナーを行う予定です*4。イベントページはまだ公開していないのですが、JFrogのconnpassをウォッチしておいていただければ最新情報が流れるようにします！よければこちらもぜひ。
最後に、皆様どうか体も心も健康にお過ごしくださいね。
参考文献 (いずれも2020年4月15日時点での閲覧)
