사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
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.
