osFoundry / Platform
ビルドパイプライン＆CI
プッシュごとにインストール→lint→ビルド→デプロイが起動。ログはストリーミング、成果物は保持。
概要
ビルドパイプラインとCIは、osFoundryのアプリとバックエンドを支える継続的インテグレーションの層です。アプリのコードをプッシュすると、osFoundryは決まった順序で処理を実行します。依存関係のインストール、Lint、ビルド、そしてデプロイです。別途CIサービスを接続する必要はなく、YAMLを手書きする必要も、ランナーを用意する必要もありません。パイプラインはワークスペースの一部なので、アプリを出荷することは、そこに作業内容を保存することと同じ操作になります。
osFoundryの内部では、このパイプラインがコードのプッシュを稼働中のアプリへと変えます。各ステージは順番に実行され、最初の失敗で停止します。そのため、Lintエラーやビルドのミスがデプロイまで届くことはありません。実行中は各ステージのログがそのまま手元に流れてくるので、インストールの出力、Lintの警告、ビルドのエラーをリアルタイムで確認できます。赤いバツ印を待ってから後でダンプを掘り返す必要はありません。ビルドが成功すると、生成された成果物が保持されます。デプロイした各バージョンは、終わった瞬間に消えるビルドではなく、あとから見返せる記録として残ります。
この点が効いてくるのは、出荷で時間を食うのが、たいていデプロイの失敗とその原因を理解するまでの往復だからです。ログがそのまま流れてくれば、この往復は短くなります。実行がどのステージのどの行で壊れたのかを、チャット、エージェント、コード、データを扱うのと同じワークスペースの中で確認できます。osFoundryはBYOKでローカルファーストなので、このパイプラインは、鍵とデータを自分の手元に置いておくワークフローに馴染みます。座席課金の料金体系を持ち、ログを自社に保存するサードパーティのCIベンダーに、ビルドの工程を預けずに済みます。
主な機能
- プッシュのたびに、インストール、Lint、ビルド、デプロイの4ステージが同じ順序で実行される
- 最初に失敗したステージでパイプラインが停止するので、壊れたビルドがデプロイされない
- 各ステージのログは実行の完了後ではなく、実行中にリアルタイムで流れてくる
- ビルド成果物はバージョンごとに保持され、出荷した内容が記録として残る
- 別途のCIサービスやランナー、手書きのYAMLは不要で、ワークスペースに組み込まれている
活用例
- 個人開発者：アプリをプッシュしてインストール、Lint、ビルドの流れをリアルタイムで確認し、デプロイの前にLintの失敗を捉える
- 社内アプリを出荷する小規模チーム：インストール、Lint、ビルド、デプロイの決まった順序に任せ、未レビューや壊れたビルドがユーザーに届かないようにする
- デプロイをデバッグする開発者：過去の実行で保持された成果物とログをたどり、どのステージでバージョンが壊れたのかを特定する
よくある質問
osFoundryのアプリにコードをプッシュすると何が実行されますか
決まったパイプラインです。依存関係のインストール、Lint、ビルド、そしてデプロイの順に実行されます。ステージは順番に走り、最初に失敗したところでパイプラインが停止するので、Lintやビルドがこけたままデプロイのステージまで進むことはありません。
実行中にビルドログを確認できますか
できます。各ステージのログは実行中にそのまま手元に流れてくるので、インストール、Lint、ビルドの出力をリアルタイムで確認できます。実行の完了を待ってから静的なダンプを読む必要はありません。
デプロイした後、古いビルドは残りますか
残ります。成功したビルドの成果物は保持されるので、デプロイした各バージョンは、完了した瞬間に消えるのではなく、あとから見返せる記録として残ります。