Appearance

Build, base de donnees, uSync, deploiement ​

Build ​

  • Backend : dotnet build UmbracoBaseTemplate.sln (.NET 10). dotnet run --project src/Web/Web.csproj pour lancer en local.
  • Frontend : depuis src/Web, npm ci + npm run build:prod (lint + Vite prod). Voir frontend-build.md.
  • Web.csproj : CopyRazorGenerateFilesToPublishDirectory=true (vues backoffice), rewriteRules.xml copie en sortie/publish (PreserveNewest), ICU app-local (Microsoft.ICU.ICU4C.Runtime).

Base de donnees ​

  • SQL Server. Chaine par defaut (appsettings.json) : Server=localhost\sqlexpress;Database=UmbracoBaseTemplate;User Id=dev;Password=dev;TrustServerCertificate=true;, provider Microsoft.Data.SqlClient.
  • Override par appsettings.local.json (git-ignore) ou variable d'env.
  • Umbraco:CMS:Unattended:UpgradeUnattended=true : Umbraco applique les migrations au boot (pas de restauration manuelle ni d'etape d'install).

uSync ​

  • uSync 17.3.5. Config serialisee sous src/Web/uSync/v17/ (ContentTypes, DataTypes, Dictionary, Languages, MediaTypes, MemberTypes, Templates).
  • Reglages (appsettings.json) : ExportOnSave="Settings", ImportAtStartup="Settings", UIEnabledGroups="Settings". Le handler Dictionnaire est en CreateOnly (les traductions ne sont pas ecrasees a l'import).
  • Workflow : modifier dans le backoffice -> uSync exporte les .config ; au demarrage, uSync importe le groupe Settings.

Docker ​

hosting/Dockerfile (build multi-stage .NET 10, build depuis la racine du repo, pas depuis hosting/) :

dockerfile
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ./src/Web/ ./
RUN dotnet restore
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
# Metadonnees de version source (consommees par le dashboard backoffice "Système").
ARG GIT_COMMIT_COUNT=""
ARG GIT_COMMIT_SHA=""
ARG GIT_COMMIT_DATE=""
ENV GIT_COMMIT_COUNT=${GIT_COMMIT_COUNT} \
    GIT_COMMIT_SHA=${GIT_COMMIT_SHA} \
    GIT_COMMIT_DATE=${GIT_COMMIT_DATE}
ENTRYPOINT ["dotnet", "Web.dll"]

Build / push :

bash
docker build -t columbia-registry.spektrum.media/umb_<site>:<env> -f hosting/Dockerfile .
docker push columbia-registry.spektrum.media/umb_<site>:<env>

<site> = nom du site avec tirets, <env> = staging ou production.

Version affichee dans le dashboard "Système" : les ARG/ENV GIT_COMMIT_* du stage runtime alimentent la boite "Version & build" du backoffice (voir modules/backoffice.md). Pour renseigner la version au build, passer les infos git en --build-arg :

bash
docker build \
  --build-arg GIT_COMMIT_COUNT="$(git rev-list --count HEAD)" \
  --build-arg GIT_COMMIT_SHA="$(git rev-parse --short HEAD)" \
  --build-arg GIT_COMMIT_DATE="$(git log -1 --format=%cI)" \
  -t columbia-registry.spektrum.media/umb_<site>:<env> -f hosting/Dockerfile .

Sans ces --build-arg, la version tombe sur 1.0.0.dev (l'image runtime aspnet:10.0 ne contient pas git : aucun fallback CLI, la version vient uniquement des env vars). Le .gitlab-ci.yml du template ne construit pas d'image Docker (build/push manuels) : il n'y a donc pas de job CI ou passer ces build-args. Un projet aval qui ajoute un job docker en CI doit y injecter les --build-arg lui-meme.

hosting/docker-compose.yml (exemple a adapter, placeholders <mon-site>/<env>/<mon-port-externe>) : monte appsettings.json (ro), media/, logs/ en volumes, reseau externe app-network, ASPNETCORE_ENVIRONMENT=Staging, ASPNETCORE_URLS=http://*:5000, forwarded headers actives.

CI/CD (GitLab) ​

.gitlab-ci.yml. Le pipeline applicatif (stage build) :

  • build:backend : image dotnet/sdk:10.0, dotnet build ... --configuration Release.
  • build:frontend : image node:22.12.0, cd src/Web && npm ci && npm run build:prod.

workflow.rules limite le pipeline aux merge requests ciblant master et aux commits sur master.

Un bloc docs (composant sync-claude-docs) a ete ajoute pour synchroniser .claude/docs/** vers le site de doc interne sur master/main/staging (gate sur changements de .claude/docs/**). Voir le .gitlab-ci.yml et la note CI plus bas.

Sentry ​

Charge uniquement en Staging/Production et si SentryUrl est defini (appsettings.json, vide par defaut, a injecter sans le committer). Prod : TracesSampleRate=0.1. Staging : ProfilingIntegration a 500 ms et Debug=true.

URL rewrites ​

src/Web/rewriteRules.xml (format IIS) applique via app.UseRewriter() en Staging/Production uniquement.

Breaking change Umbraco 17.4 - URL applicative ​

Depuis 17.4, la detection auto de l'URL via le header Host est optionnelle (risque de spoofing sur emails de reset/invitation). Le template fournit une section vide Umbraco:CMS:WebRouting:UmbracoApplicationUrl. Tout projet aval derriere un reverse proxy doit la renseigner (appsettings de prod ou variable d'env Umbraco__CMS__WebRouting__UmbracoApplicationUrl).

Contributors

No contributors

Changelog

No recent changes