Blog - Od commita do publikacji

Jeśli blog ma działać „bezobsługowo”, to w praktyce liczy się by publikacja nowego posta przebiegała jak najprosciej się da, czyli w moim przypadku:

    
  
  flowchart LR
    A[📝 Piszę artykuł] --> B[✅ Commit do repo]
    B --> C[🌐 Nowy wpis na blogu]
    

W tym wpisie przedstawie jak publikuje wpisy na Blog.IronFlow.PL.

Założenia:

• środowisko Microsoft
• artykuły w markdown
• minimalne środowisko
• automatyzacja publikacji

Co dokładnie składa się na środowisko blog.ironflow.pl?

Całość można opisać trzema klockami:

1. Hugo (generator statyczny)
   Piszę wpisy w Markdown, a Hugo generuje z nich statyczne HTML/CSS/JS.

2. Azure DevOps (repo + pipeline)
   Repo przechowuje kod i treści, a pipeline buduje i publikuje stronę po zmianach.

3. Azure Static Web Apps (hosting, free/personal)
   Hostuje wynik buildu (z public/), obsługuje custom domain i HTTPS.

Składniki:

- Hugo (generator stron statycznych + markdown dla artykułów)
- Motyw Geeky (gotowy szablon z małymi zmianami)
- Visual Studio Code (IDE)
- Azure Static Web Apps (hosting kontentu)
- Azure DevOps
    - Pipeline (automatyzacja procesu publikacji)
    - Repozytorium kodu (repozytorium kodu)

    
architecture-beta
  group dev(material-icon-theme:vscode)[Dev PC]
  service vscode(material-icon-theme:markdown)[VS Code] in dev

  group azuredevops(cloud)[Azure DevOps]
  service repo(devicon:azuredevops)[Azure Repos] in azuredevops
  service pipe(material-icon-theme:azure-pipelines)[Azure Pipelines] in azuredevops
  service build(devicon:hugo)[Hugo Builder] in azuredevops

  group hosting(material-icon-theme:webpack)[Hosting]
  service swa(logos:azure)[Azure Static Web Apps] in hosting

  vscode:R --> L:repo
  repo:R   --> L:pipe
  pipe:B   --> T:build
  build:T  --> B:pipe
  pipe:R   --> L:swa

Repo: co trzymam w kodzie?

W repozytorium znajdują się:

• treści wpisów w Markdown (np. content/blog/*.md),
• konfiguracja Hugo,
• motyw (u mnie jako katalog nadrzędny, co ma znaczenie w pipeline).

Lokalny workflow (pisanie i podgląd)

Pisanie nowego wpisy wyglada u mnie tak:

1. Tworzę/edytuje plik dla danego wpisu w content/blog/.
2. Lokalnie odpalam podgląd by zobaczyć jak wygląda tekst osadzony w motywie:
   • hugo server
3. Wersja zaakceptowano to daje “commit + push” do repo na Azure DevOps.
4. Pipeline robi resztę: buduje i publikuje na Azure Static WebApp.
5. Weryfikacja czy wpis widoczny i czy wyglada zgodnie z wersją z podglądu na lokalu.

CI/CD: Azure DevOps Pipeline krok po kroku

Najważniejsza część automatyzacji to plik azure-pipelines.yml. Poniżej opisuję jego kluczowe fragmenty.

Trigger: kiedy pipeline się uruchamia?

trigger:
  - master

Pipeline uruchamia się automatycznie przy każdym pushu do gałęzi master.

Wersja Hugo jako zmienna

variables:
  hugo.version: '0.147.2'

Wersję Hugo Extended trzymamy w jednym miejscu, co ułatwia późniejsze aktualizacje.

Stage oraz agent

stages:
  - stage: 'GenerateBlogIF'
    displayName: 'Generate IronFlow blog'
    jobs:
      - job:
        pool:
          vmImage: ubuntu-latest
        workspace:
          clean: all

Agent bazuje na ubuntu-latest.
clean: all usuwa poprzednie artefakty — build zaczyna się zawsze „na czysto”.

Instalacja Hugo Extended

- script: wget https://github.com/gohugoio/hugo/releases/download/v$(hugo.version)/hugo_extended_$(hugo.version)_linux-amd64.deb -O '$(Pipeline.Workspace)/hugo_extended_$(hugo.version)_linux-amd64.deb'
  displayName: Download Hugo $(hugo.version) Linux x64

- script: sudo dpkg -i $(Pipeline.Workspace)/hugo*.deb
  displayName: Install Hugo

Pobiera pełną wersję Hugo Extended, wspierającą SCSS i Hugo Pipes.
Instalacja .deb zapewnia dostępność polecenia hugo w dalszych krokach.

Wdrożenie na środowisko produkcyjne (master)

- task: AzureStaticWebApp@0
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/master')
  inputs:
    app_location: '/'
    app_build_command: 'hugo --minify --themesDir ../..'
    output_location: '/public'
    azure_static_web_apps_api_token: '$(TOKEN)'

Wykonywane wyłącznie dla gałęzi master.
hugo --minify — buduje bez draftów, idealne dla produkcji.
Token $(TOKEN) to klucz do instancji production w Azure Static Web Apps.

Cały pipeline

trigger:
  - master

variables:
  hugo.version: '0.147.2'

stages:
  - stage: 'GenerateBlogIF'
    displayName: 'Generate IronFlow blog'
    jobs:
      - job:
        pool:
          vmImage: ubuntu-latest
        workspace:
          clean: all
        steps:
        - checkout: self
          displayName: 'Checkout repository including submodules'
          submodules: true  # true so Hugo theme submodule is checked out
        - script: wget https://github.com/gohugoio/hugo/releases/download/v$(hugo.version)/hugo_extended_$(hugo.version)_linux-amd64.deb -O '$(Pipeline.Workspace)/hugo_extended_$(hugo.version)_linux-amd64.deb'
          displayName: Download Hugo $(hugo.version) Linux x64
        # 2. Installs Hugo executable
        - script: sudo dpkg -i $(Pipeline.Workspace)/hugo*.deb
          displayName: Install Hugo          
        - task: AzureStaticWebApp@0
          condition: eq(variables['Build.SourceBranch'], 'refs/heads/master')
          inputs:
            app_location: '/'
            app_build_command: 'hugo --minify --themesDir ../..'
            output_location: '/public'
            azure_static_web_apps_api_token: '$(TOKEN)'
        
        - task: AzureStaticWebApp@0
          condition: ne(variables['Build.SourceBranch'], 'refs/heads/master')
          inputs:
            app_location: '/'
            app_build_command: 'hugo --minify  --themesDir ../..'
            output_location: '/public'
            azure_static_web_apps_api_token: '$(STAGING_TOKEN)'