DevOpsを加速する、JFrog日本法人メンバーによるブログです。JFrog ArtifactoryやXrayといった自社ツールはもちろん、CI/CDやコンテナ技術(DockerやKubernetes)などDevOpsの一般的な内容も扱います。その他、日本でのDevOps事例紹介やお楽しみコンテンツも掲載予定です。

JFrogならではの面白くて役に立つブログを目指しますので、お楽しみに!

ソフトウェアのアーティファクトって何?

JFrogディベロッパーアドボケイトのよこなです🐸

アーティファクト」って聞いたことありますか?
日本だと、そんなに馴染みがない方や、意味は分かるけど常用はしないという方も多いのではないでしょうか?と言っても日本以外での浸透具合を知っているわけではないのですが、少なくともウィキペディアに英語や中国語のページはあるのに対し、日本語版はありません*1

JFrogでは、DevOpsを語るときにしばしば「アーティファクトの管理が大事ですよ」という話をします。
今回はその前提知識とも言える、そもそもアーティファクトとは何なのかについて書いていきます。

アーティファクトとは副産物のこと

ソフトウェア開発において、アーティファクトとは「ソフトウェアを作る過程で生み出されたもの」を指します。
クラス図、ソースコード、デザインファイル、テストのエビデンス、ログファイルなどなど。広義では、あれもこれもアーティファクトです。

f:id:ihcomega:20200416152915p:plain
広義のアーティファクト

文脈によって変わるアーティファクトの意味

一方、話のスコープが狭まるとアーティファクトが指すものも変わってきます。
例えば特定の環境 (開発環境、ステージング環境、本番環境など) に限った話をしているときはその環境で作られた成果物を指しているかもしれません。コードをGitリポジトリにプッシュしてからデプロイまで実行するCIについて話しているならば、プッシュ前にローカルでできたファイルなどは対象から外れることもあるでしょう。また、npmやgem, Mavenなどパッケージマネージャーが話題の中心なら、ビルドした結果のバイナリファイルをアーティファクトと呼ぶこともあります。

DevOpsでしばしば登場するアーティファクト

冒頭で触れたJFrogが管理しましょうねと言っているアーティファクトは、多くの場合パッケージマネージャーやDockerなどを用いてビルドを行った際にできるファイルを指しています。いわゆるバイナリファイルですね。
JFrogに限らず、DevOpsを促進するようなツールや会社のサイトを訪れると同様に「アーティファクト (英語サイトではartifact) 」という言葉が使われています*2。 本記事では以下、この意味でアーティファクトという言葉を用います。

f:id:ihcomega:20200416152950p:plain
DevOpsで登場するアーティファクト

同じものを示す様々な表現に要注意

日本語でアーティファクトのことを表現する方法は結構たくさんあります。「バイナリ」、「成果物」、「ビルド成果物」・・・。口頭だともっとくだけて「ツール使って固めたやつ」、「パッケージマネージャーが吐き出したもの」みたいな言い方でも通じることがあります(よね?)。
例えばソースコードの管理あたりと比べても、アーティファクトの管理はまだまだ定着していないし語られる頻度も少ないため、皆が標準的に使う言葉が決まっていないのかもしれませんね。

アーティファクトのプロフィールのような存在「メタデータ

ちょっとだけアーティファクト自体の定義を一歩踏み出た話をします。アーティファクトとセットで大事な情報を持つ「メタデータ」についてです。
アーティファクトは多くの場合バイナリファイルなので、ほとんどの人間はそのまま読むことができません。そのため、そのバイナリの特徴をメタデータとして付与します。ビルドした人の名前、ビルドしたサービスの名前、リリースバージョン、ビルド実行時刻、ビルド実行環境などを別ファイルやツールにより分かるようにしておくのです。

アーティファクトはリリース時にある環境から別の環境へ移したり、エンジニア間でシェアしたりすることがあるので、メタデータを使って見分けることで、作業対象を誤らずに見分けることができます。

なお、複数の技術やパッケージマネージャーを使っている場合、メタデータの付与方法や形式も異なるので、「どんなアーティファクトであっても必ず欲しい情報」を同じ方法で取得できるとは限りません。そこで、アーティファクトを統合的に管理する「バイナリ・リポジトリマネージャー」を用いると、あらゆるものに対して一貫性のある管理を行うことができます*3


アーティファクトについて完全マスターしたところで、今回はここまでです!正直な話、私が数ヶ月前に「アーティファクトって日本語で何だ?」と疑問に思ったものの日本語だとあまり資料がなく困ったので書いてみました。「アーティファクトとは」「アーティファクト 何」なんて検索した方がここにたどり着いて疑問を解消してくだされば幸いです😏

アーティファクトの管理についてはまたブログ書きます!ツールの使い方とかも紹介する予定です。

あとお得情報なのですが、4月30日(木)に実践的なアーティファクト管理についてウェビナーを行う予定です*4。イベントページはまだ公開していないのですが、JFrogのconnpassをウォッチしておいていただければ最新情報が流れるようにします!よければこちらもぜひ。

最後に、皆様どうか体も心も健康にお過ごしくださいね。

参考文献 (いずれも2020年4月15日時点での閲覧)

*1:記事を書いている2020年4月現在

*2:参考文献として貼ったMicrosoft AzureやGitHubのページにもありました

*3:JFrogが提供しているArtifactoryもそうした使い方ができるツールです。

*4:余談ですが、この記事はこのウェビナーの宣伝のためじゃなく純粋にアーティファクトを解説しようと書いたものです。たまたま時期がかぶって二度美味しい感じになりました。へへ…

JFrogの考えるDevOpsってどんなもの?

TL;DR


先月入社したディベロッパーアドボケイトのよこな (Twitter: @ihcomega) です🐸JFrog日本支社、ブログはじめました🍜

JFrogはイスラエルに本社をおく、DevOpsを助けるツールをつくっている会社 (https://jfrog.com/) です。
もちろんそれをビジネスとしている以上は多くの方に使っていただき、皆が知っていて当たり前なツールを目指していきたいものですが、このブログではそういったプロダクトにべったりなネタも、そうじゃないものもたくさん書くつもりです!

なお、せっかくグローバル企業の日本支社でやるので、本社から来るJFrogの最新情報を取り扱いつつも日本の状況をふまえた内容にしたり、英語の情報を日本語に変えてお届けしたり、私達らしいコンテンツを目指します💪


さて、JFrogに入ってから「DevOpsって何だろう?」とよく考えています。プロダクトがDevOpsに関するものだし、ここ最近国内での関心の高まりも感じるからです。DevOpsは10年ほど前に生まれた概念*1なので、日本でも既に事例は山程あり有識者もたくさんいらっしゃいますが、広い広いIT業界を見渡すと、まだ浸透しきったとは言えず、これからといったところのようです。

私も今までのキャリアではエンジニアとしてものを作っていたので、今考えればDevOpsらしいことは多少やってきました。
ただ、別に「よし、DevOpsをやるぞ!」「今の組織ではDevOpsできているなぁ」などとそれ自体をめっちゃ意識して生きていたわけではないため、最近改めて考えているというわけです。DevOpsって便利な道具のように明確に姿が確認できるわけでもなければ、明日から取り入れたらそれで終わりという単純なものでもないんですよね。
個人的には方法論というより、ずっと念頭に置いて改善のため取り組み続けるものというイメージを持っています *2

そんな、なかなか言語化や定義の難しいDevOpsですが、世の中には有識者によって表現された「DevOpsとは何か」論がたくさんあります(貴い)。

JFrogもDevOpsについてこんなページで説明しています:
jfrog.com

今回は上記を日本語にしつつ、理解しやすいよう読み物スライドにしてみました!
これからDevOpsについて考える方はぜひ参考にしてください🐸既にDevOpsを完全にマスターした方はぜひどう思われたか教えて下さい🐸

ここ最近オフラインのイベントができない状況なので色々な方と会って議論して深めていくということはしばらくおあずけですが (入社早々ディベロッパーアドボケイトにはとてもつらい状況になってしまった…でも皆さんどうか健康に) 、落ち着いたら色々なところに顔出すのでよろしくお願いします〜!

*1:『Effective DevOps』によると2009年のVelocity(カンファレンス)でFlickerのエンジニアがDevとOpsの協業について語ったあたりから興ったようです

*2:ちなみに今日現在、Wikipediaには明確に開発手法の一つと書かれています。どう捉えるかは色々ですね