こんにちは！EX開発部の佐藤(諒)です。 11/26にSalesforce Developer Groupの「Dreamforce2021 Global Gathering Tokyo」が行われ、 そこで TeamSpirit EX を最新技術 2GP(第二世代パッケージ)化した話を発表してきました。
こちらは チームスピリット Advent Calendar 2021 - Adventar の18日目の記事です。 adventar.org
発表の様子
昨今の情勢もあり、ほとんどの方はリモートで参加されておりましたが、 ちょうどコロナが落ち着いてきた関係もあり、社内で発表をすることができました。 その時ちょうど社内で懇親会を開いていた関係もあり、会社の部署問わずに話を聞いていただけました。
発表内容について：第二世代パッケージの導入・効果・運用
発表の内容はTeamSpirit EXに第二世代パッケージを導入した際の導入方法・導入の効果・導入後の運用方法を包括的に発表しました。 導入の方法や導入の運用法はスライドを見ていただくとして、 ここでは特に印象に残っている導入後にどのような効果があったのか、 またこれからどうするのかを実際のエピソード・開発段階の会議を交えながら紹介したいと思います。
導入の効果
シンプルにパッケージングをCIで自動化し、パッケージングの作業時間を短縮した以外にもメリットがありました。 特に第一世代パッケージの「運」要素が無くなったことは大きなメリットでした。
パッケージングには「運」が必要？
第一世代パッケージでは、ベータパッケージを作成するにはパッケージ組織に資産をデプロイして作成する必要がありました。 開発中の資産でもパッケージ組織に資産をデプロイすれば、パッケージングを行えるかをテストすることは出来るのですが、 それを行うと本番パッケージを作成する前に開発中の資産がデプロイされていないことを目視で確認する必要があります。 特に開発中に不要になった資産があると、その資産をパッケージ組織から依存関係に注意しながら手動で削除する必要がありました。 そのためパッケージ作成のテストを開発中に行うことはできませんでした。
そのためパッケージングは全てのQAレビューが完了した後に初めて行う、 言わばぶっつけ本番の状態になっておりました。
もちろんパッケージングで行われるユニットテストなどはCIで毎日行っておりますが、 パッケージングの段階で名前空間に関する違いなどでユニットテストが失敗して3~4時間かかるテストを最初からやり直しといった問題もあり、 パッケージングには「運」が必要とまで言われることもありました。
運要素不要な第二世代パッケージ
第二世代パッケージでは、パッケージ作成にパッケージ組織にデプロイを行うことは不要になり、 単にコマンドを打つだけで既存のソースを元にパッケージを作成することが出来るようになりました。
そのためリリース前に限りますが、 第一世代のようにパッケージ作成組織を目視確認や手動で削除といったことは必要なく、 開発中に不要になった資産についてはリポジトリから削除すれば 次回のパッケージではその資産が削除された状態でパッケージが作成されるようになります。
これによりパッケージ作成を何回でもやり直すことができるようになり、 第一世代の時のようにぶっつけ本番では無くなりました。
チームスピリットではCIでパッケージ作成を毎日行うことで、 パッケージが作成できるのかどうかを毎日テストしております。
これにより、「運」要素を無くすことができるようになりました。
第二世代パッケージのこれから
現在のパッケージを第二世代パッケージにすることだけでもメリットはありますが、 第一世代パッケージになかった新しい機能を利用することでさらに開発を進めていきたいと考えております。
モノリスからの脱却
第二世代パッケージは @namespaceAccessible という同一名前空間のパッケージ間で Apex コードを共有できる機能があります。 この機能を利用してパッケージを複数のパッケージに分割して行くことが可能になりました。
将来的にはこの機能を活用することで現在モノリスになっているパッケージを分割し、 パッケージの作成範囲を絞ってリリースすることができるようにしたり、機能開発のスピードを上げていきたいと思います。
