Come usare
- Copia il comando e controlla il pacchetto prima di installarlo nel tuo ambiente agente.
- Controlla strumenti, credenziali e ambienti richiesti nel documento originale.
- Descrivi input e risultato desiderato; confronta l’output con le fonti.
npx skills add https://github.com/sociuu/sociuu-skills --skill sociuu-ship-hotfixPrima di iniziare
- L’installazione non include abbonamenti, quote API o accesso ai file.
- Stelle e installazioni indicano attività, non un test indipendente di qualità o sicurezza.
Contenuto dal repository con titoli, esempi, codice, tabelle, link e immagini preservati.
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.
