release-process

Release Process & Versioning

Overview

FaceKom releases are per-client, tagged on customization branches, and deployed manually. There is no automated release pipeline — each release is a human-driven sequence of changelog update, tagging, image build, and deployment.

Versioning Scheme

FaceKom uses a {client}-{core}.{patch} versioning scheme:

{client}-{core_version}.{client_patch}

• Core version: 1.9.11 (shared across all deployments)
• Client patch: incremental per-client, independent of other clients
• Tags are applied identically on both vuer_oss and vuer_css repos
• vuer_cv has its own semver: 4.8.3 (shared, not per-client, except telemedicina-*)
• esign services share tags with the corresponding client

Examples

Tag	Meaning
nusz-1.9.11.44	NUSZ’s 44th release on core 1.9.11
cib-1.9.11.98	CIB’s 98th release on core 1.9.11
kh-1.9.11.54	K&H’s 54th release on core 1.9.11

Release Flow

graph TD
    Dev[Developer] -->|"feature/FKITDEV-*"| PR[Pull Request]
    PR -->|merge| Branch["customization/{client}"]

    Devel[devel branch] -->|periodic merge| Update["update/customization/{client}/{date}"]
    Update -->|merge with conflict resolution| Branch

    Branch -->|update RELEASE.MD| Changelog[Changelog Commit]
    Changelog -->|git tag| TagOSS["Tag vuer_oss<br/>{client}-{version}"]
    Changelog -->|git tag| TagCSS["Tag vuer_css<br/>{client}-{version}"]

    TagOSS -->|build| Image["Docker Image<br/>harbor.techteamer.com"]
    TagCSS -->|build| Image

    Image -->|deploy| Server["Production Server"]
    Server -->|"vuer.sh checkout"| Running["Running Service"]

Process Steps

1. Feature Development

• Developer creates a feature branch: feature/FKITDEV-{ticket} or fix/FKITDEV-{ticket}
• Feature branches are based off the client’s customization branch (not devel)
• PR is opened against customization/{client}
• Example branch: TechTeamer/release/kh-1.9.11.52

2. Core Updates (Periodic)

Merge Conflict Risk

Core updates are a major source of merge conflicts. See breakage-risks for hotspot files.

• A core update merges devel into the customization branch
• Branch pattern: update/customization/{client}/{date} or update/FKITDEV-{ticket}-{client}-devel-update
• Example commits:
  • chore(customization/nusz): devel update 2025-11-02 #7428
  • Merge remote-tracking branch 'origin/devel' into update/customization/nusz/2025-11-07
  • [FKITDEV-8210] - Update/fkitdev 8210 nusz devel update (#7632)

3. Release Preparation

1. Update the changelog file (varies by client — see Release Notes Format)
2. Bump version in changelog header (e.g., ## 1.9.11.44)
3. Commit with message: {version} changelog (e.g., 1.9.11.44 changelog)
   • Some branches use: {version} release changelog

4. Tagging

• Tag the HEAD of the customization branch: {client}-{version}
• Tag must be applied to both vuer_oss and vuer_css repositories (they are kept in sync)
• Push tags to origin: git push origin {client}-{version}

5. Docker Image Build

Docker images reference versions via .env variables:

Variable	Example
VUER_VERSION	2026.1.UBI9
VUER_BUILD_NUMBER	1
SECURITY_NUMBER	20220315

Image format:

harbor.techteamer.com/{project}/{service}:{version}.{build}-{security}

Example:

harbor.techteamer.com/facekom-devel/vuer_oss:2026.1.UBI9.1-20220315

For production deployments, the PROJECT_NAME and versions differ per client. Images are pushed to Harbor: harbor.techteamer.com.

6. Deployment

Bare-metal / Supervisor deployments:

vuer.sh checkout customization/{client}

This runs: git status check → supervisor stop → git checkout + pull → yarn install → supervisor start → npm run build.

Containerized deployments:

docker-compose pull && docker-compose up -d

With client-specific .env configuration.

Release Checklist

Copy this checklist for each release

## Release Checklist: {client}-{version}
 
### Pre-Release
- [ ] All feature PRs merged to `customization/{client}`
- [ ] Core update merged if needed (`update/customization/{client}/{date}`)
- [ ] All merge conflicts resolved
- [ ] Tests passing on branch
 
### Release
- [ ] Update `customization/RELEASE.MD` with changelog
- [ ] Commit: `{version} changelog`
- [ ] Tag vuer_oss: `git tag {client}-{version}`
- [ ] Tag vuer_css: `git tag {client}-{version}` (MUST match OSS tag)
- [ ] Push tags: `git push origin {client}-{version}`
 
### Build & Deploy
- [ ] Build Docker images with updated version
- [ ] Push to Harbor: `harbor.techteamer.com/{project}/`
- [ ] On target server: `vuer.sh checkout customization/{client}` OR docker-compose update
- [ ] Verify supervisor processes running: `vuer.sh server status`
- [ ] Verify build completed: check for errors in build output
 
### Post-Deploy
- [ ] Smoke test: login to OSS, open a room, take a screenshot
- [ ] Check logs for errors: `vuer.sh log`
- [ ] Verify version in UI or API response
- [ ] Update YouTrack tickets to "Deployed"

Release Counts (as of 2026-03-18)

Client	Latest OSS Tag	Total Releases	Release File
cib	cib-1.9.11.98	99	customization/RELEASE.MD
mkb-instant	mkb-instant-1.9.11.64	65	RELEASE.md (in customization/)
kh	kh-1.9.11.54	64	(changelog in commits)
mvm	mvm-1.9.11.64	64	RELEASE.md
instacash	instacash-v2-phase2-1.9.11.37	59	RELEASE.md (in customization/)
dap	dap-1.9.11.57	57	(no release file)
microsec	microsec-1.9.11.39	51	(no release file)
bb	bb-1.9.11.42	50	RELEASE.md
mbh	mbh-1.9.11.34	47	(no release file, has releaselog.md)
nusz	nusz-1.9.11.44	45	customization/RELEASE.MD
magnet	magnet-1.9.11.35	37	RELEASE.md
demo	demo-1.9.11.27	29	(no release file)
generali-atvilagitas	generali-atvilagitas-1.9.11.13	14	(no release file)
polgaribank	polgaribank-1.9.11.9	9	(no release file)
fundamenta	fundamenta-1.9.11.3	8	(no release file)
barion	barion-1.9.11.5	5	(no release file)
granit	granit-1.9.11.4	5	(no release file)

Note

CSS tags match OSS tags exactly for each client.

Release Notes Format

Different clients use different changelog formats:

NUSZ (customization/RELEASE.MD)

## 1.9.11.44
- CRNUSZ-99: Riport idopontfoglalasokrol
 
## 1.9.11.43
- altalanos rendszerfrissites
- CRNUSZ-101: Email igazitasa

CIB (customization/RELEASE.MD)

## [1.9.11.98] - 2026-03-10
- CRCIB-82: Javitva lett az email API-tol kapott valaszok logolasa

MVM (RELEASE.md)

### 1.9.11.64
- [SLAMVM-441](youtrack-link) MVM TCT megjelent hivas...

Cofidis (RELEASE.md)

### 1.9.11.42
 - FKITDEV-8163: Recaptcha kikapcsolasa

Raiffeisen (RELEASE.md)

# 1.9.11.88
- SLARAFIPI-48 Salesfunnel issues

Ticket Prefix Convention

Client	Bug Prefix	Feature Prefix	SLA Prefix
NUSZ	BUGNUSZ-*	CRNUSZ-*, FKPRE-*	SLANUSZ-*
CIB	BUGCIB-*	CRCIB-*	SLACIB-*
MVM	BUGMVM-*	CRMVM-*	SLAMVM-*
Raiffeisen	—	CRRAFIPI-*	SLARAFIPI-*
MKB	—	CRMBHKIOS-*	—
Magnet	—	CRMNET-*, ASSMNET-*	—
General	FKITDEV-*	FKITDEV-*	—
QA	FKQA-*	FKQA-*	—

The vuer.sh CLI Tool

Located at /workspace/vuer_docker/bin/vuer.sh. Key commands for release operations:

Command	What It Does
vuer.sh checkout customization/{client}	Full branch switch: stop → checkout → pull → yarn → start → build
vuer.sh server status	Show supervisor process status
vuer.sh server restart [process]	Restart specific or all supervisor processes
vuer.sh server stop [process]	Stop processes
vuer.sh dev build	Build scripts and styles
vuer.sh dev install	Run yarn
vuer.sh dev watch	Watch mode with auto-rebuild
vuer.sh docker update	Pull latest images and restart containers
vuer.sh log [file]	Tail log files
vuer.sh git status	Check for uncommitted changes
vuer.sh db init	Create default admin/operator users

Can target specific services: vuer (oss+css), esign (oss+css), or individual service names.

CI/CD

• Travis CI: Runs on push, Node.js 22, with Docker/PostgreSQL/RabbitMQ services
• GitHub Actions:
  • audit.yaml — dependency audit
  • pull-request.yaml — PR checks
• No automated release pipeline — releases are manual (tag + push to Harbor)

Related

• FaceKom — Platform overview
• customization-branches — 21 active client deployments
• breakage-risks — Core file merge conflict hotspots
• infrastructure — Docker, Nginx, monitoring
• vuer_oss — Backend architecture
• vuer_css — Frontend architecture