This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We're always looking for talents to join our team check out our careers page!

導入

羽では、我々はシンプルで効率的なソリューションが大好きです.我々は、連続的な発展と最短反復サイクルとの連続積分をしっかりと信じている.私たちのワークフローは、一日数百回生産を展開する必要があるように設計される必要があります.
我々は、最初から自動テストに投資されている:我々は、ユニットテスト、統合テスト、エンドツーエンドのテストを実行し、もっと.我々は、我々が発展している間、何も壊さないと確信しています.
我々は、我々の速度をできるだけ高く保つためにTrunk Based Developmentを使用してFeatures Togglesに触発された分岐政策を使用します.バージョン管理のために、我々はGithubと我々の連続的な統合と連続的な開発をGitHub Actionsで実行しています.これについてもっと学ぶために、私たちの記事をチェックしてください.
この記事では、リリースポリシーと展開ポリシーについて説明します.我々はチームの重要な変更を更新し、我々の開発のワークフローに統合しているみんなを維持する方法を発見した.

コードの配備

メインブランチにプッシュされたすべてのコミットがステージングビルドを引き起こします.これに加えて、メインブランチにプッシュされたすべてのコミットは、release drafterの助けを借りてGithubの新しいリリースを作成します.
作成されたリリースでは、以前のリリース以降に追加されたすべてのコミットが含まれます.提案された新しいバージョンはSemantic Versioningルールに従っています.
我々のコードを生産に配備するために、我々は単にGithubで「公開リリース」ボタンをクリックする必要があります.そこから、Githubアクションは引き継がれ、次のように注意します.

コードを生成します.

は、新しいリリースに関してチーム(スラックに関して)を展開して、彼らに何が変わったかについて知らせさせます.

起草されたリリースのうちの1つに

のバージョンをバンプし、ギタブに変更を押してください.

リリース一覧✅

リリースを公開するには、次のようにします.

は、semverが正しい

であることを確認します

は、「生のchangelog」セクションが

を展開したい変更を含むことを確認します

は、「何が変わったか」セクションが記述的に十分であることを確認します.これは非Techies🤓

すべてが正しいなら✅, をクリックしてください.バージョンはすぐにライブになるとchangelog全体のチームに送信されます.

リリースノート

チームの誰もが私たちのリリースノートに従っているので、彼らは読みやすいようにする必要があります.そういうわけで、私たちは2つのセクションにメモを分けました:リリースを公開している人とすべてのコミットメッセージのコンパイルされた生のchangelogによって加えられるハイレベルの概要.
プロジェクトには、リリースのDraftterテンプレートを使用できます.

name-template: 'app: v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
template: |
  # What’s Changed 🤩
  _Please insert human readable changelog based on the raw changelog_
  # Raw changelog 📃
  $CHANGES

それは我々のスラックのように見えます: