0時に寝て6時に起きた。
docker object labels と git リビジョン
継続的デリバリーのために snapshot jar のマニフェストから取得した git のリビジョンを docker イメージの labels に追加するサンプルコードを jib-sample に実装してみた。jib の gradle プラグインを作って簡略化すれば便利かもしれない。
0時に寝て6時に起きた。
継続的デリバリーのために snapshot jar のマニフェストから取得した git のリビジョンを docker イメージの labels に追加するサンプルコードを jib-sample に実装してみた。jib の gradle プラグインを作って簡略化すれば便利かもしれない。
0時に寝て3時に起きて6時ぐらいまでだらだらして寝て7時に起きた。
昨日 jar に git のリビジョン番号を含める ことについて書いた。jar から git のリビジョン番号を取得できれば、docker イメージを生成するときに labels に jar の artifact id と git のリビジョン番号のラベルを追加して、docker イメージからもソースコードの追跡ができるようになる。いまデプロイは docker イメージのみで運用しているため、maven のバージョン管理ができなくても docker イメージの追跡可能性さえあれば現実の運用で問題にならないのではないかと考えた。つまり、snapshot jar で開発したものをそのまま本番環境にデプロイするということを意味する。こうすれば特定のバージョン番号を付けるだけのビルドとデプロイが不要になって、テスト環境にデプロイされた docker イメージのテストを完了すれば、そのイメージをいつでも本番環境にデプロイできるようになる。デプロイするタイミングでビルドする必要がなくなるので継続的デリバリーに近づくのではないかと考えた。
今日、開発の偉い人やインフラ担当者も含めて、みんなでわいわい打ち合わせして、現状の開発では、インターフェースや互換性の変更にあわせてバージョン番号を付けていないし、古いバージョンに戻すことも現実にはなく、保守は常に最新のリビジョンを更新していくから maven でバージョン管理できなくなっても snapshot jar の運用でがんがん開発していけばいいんちゃうという合意を得られた。
実際にこのやり方がうまくいくかどうか、私も初めての試みなのでやってみないとわからないが、この運用によるワークフローの効率化のメリットも大きいので、引き続き、イニシアティブをもって取り組んでいきたい。