Azure Pipelinesには、アプリケーションをデプロイするためのリリースパイプラインを、GUIで作る機能がありました。 この機能は大変便利なのですが、既に「Classic」と表現されていて、徐々に消えていく運命にあります。 今からやるなら、ビルド/リリースパイプラインの定義をYAMLで作り、ソースリポジトリと一緒に管理していくのがよい、とされています。 Azure PipelinesにもYAMLを使ったビルドパイプラインを作る機能があるのですが、悲しいかな仮想マシンに対してアプリケーションをデプロイすることが、標準的な方法では準備されていませんでした。 しかし、2019年末のSprint 162で、Azure Pipelinesから仮想マシンにデプロイするための機能が入りましたので、その中身を軽く確認してみようと思います。 Classicなリリースパイプラインで使っていた「Depl
2020-07-11: Cloud Buildでの記述が誤っていたので修正しました。 はじめに 今年のゴールデンウィークは暇があり、勤務先で複数のリポジトリを使っているのが辛く感じてきていたため、monorepoについて調べてみました。monorepoについての説明やメリットについては他の記事に譲ります。 www.graat.co.jp この参考記事でmonorepoの本当の課題として挙げられている以下の4点のうち、3点目に相当する「CIで変更によって影響を受けた部分だけをビルドする方法」を調査・検討しました。 トランクベース開発は、より一段と重要になります すべてのサービスがモノレポで上手く動くわけではありません より精巧なCIセットアップが必要です あなたは大規模な変更について考える必要があります この参考記事ではnxが挙げられていますが、nxは主にJavaScriptのプロジェクトを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
