使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/sociuu/sociuu-skills --skill sociuu-ship-hotfix開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Sociuu Ship Hotfix
A hotfix ships one reviewed fix on top of the exact version running in Production without releasing unreleased work from the integration branch. All deployable Sociuu repositories share this release model; confirm job names in each repository's .gitlab-ci.yml before acting.
| Ref | Deploys |
|---|---|
Integration branch (poc; Prime main) | Staging, automatically |
| Release tag (each repository's series) | Demo automatically; Production through the manual <APP>/PRODUCTION job |
Prime releases two applications, HOUSTON and MYHUB; treat each as its own release.
The explicit request authorizes the steps below for the named fix and repositories, except the actions the release owner's own instructions control: pushing a tag, playing a Production job, writing to Production, merging, and the release policy mode. Where those instructions are silent, the mode is manual and the release owner confirms each one in chat. A failed release needs a new explicit decision to roll back or roll forward.
Procedure
- Scope. Identify the reviewed fix (MR or commits), its ClickUp task, and
every affected repository and application. Confirm its tests and review passed.
- Baseline. For each application, find the tag of the last successful
<APP>/PRODUCTION job and confirm it against the running version. Filter by job: Houston and MyHub share one permanent/production environment. If the integration branch has nothing unreleased beyond that tag, stop and use an ordinary release.
- Branch. In a task worktree, create
hotfix/<task-key>from that tag and
apply only the fix. Keep conflict resolution minimal and run the repository's focused tests.
- Merge-back MR. Open an MR from the hotfix branch to the integration
branch, noting any original MR it replaces.
- Collisions. Check that no other tag pipeline or Production deployment
is running, and ask the release owner to tell the team before tagging.
- Tag. Run
git fetch --tagsand push the next unused number in the
repository's series (see release contents) on the hotfix branch head; tags are never moved or reused. For several repositories, release providers before consumers (Apex before Fuse and Prime) unless the change requires another order.
- Demo. Wait for the Demo deployment and verify the fix and adjacent
behaviour on Demo. If Demo fails, stop before Production and report.
- Production. Record the error baseline, then play
<APP>/PRODUCTION
under the authority above. Verify the deploy chain, migrations, the fix and error monitoring with production checks before releasing the next application.
- Finish. Ask the release owner to close the team notice. After the
merge-back MR is merged, close any superseded original MR. Run sociuu-release-notes for the hotfix: it posts the task's release-note comment and, when the release owner wants one, writes the #dev_updates note. Then set the task to complete.
Report the exact tags, deployments, verification results, open MRs and any human action still required. A tag or a green pipeline alone is not a Production release.
