PlantUML ile Diagrams-as-Code: Söz Dizimi, C4-PlantUML, include'lar ve CI'da Render

Sürüm notu: Bu yazıdaki diyagramlar UML (Unified Modeling Language) 2.5.1 ve C4 (Context, Containers, Components, Code) notasyonuyla, PlantUML 1.2026.9, C4-PlantUML 2.14.0, Java 21 (Temurin 21.0.13) ve Graphviz 16.1 (WebAssembly derlemesi) ile render edilmiştir; serinin C# kodları .NET 10 ile denenmiştir.

Önce Tahmin Et: Bu Diff'te Ne Değişti?

İK (insan kaynakları) Portalı ekibinde biri sequence diagram'ı güncelleyip bir PR (pull request) açıyor. Repo'da diyagramın hem kaynağı hem de PNG (Portable Network Graphics) hali duruyor. git diff'in gerçek çıktısı:

 submit.png  | Bin 11400 -> 11949 bytes
 submit.puml |   2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/submit.png b/submit.png
index 53a980c..c6b0416 100644
Binary files a/submit.png and b/submit.png differ
diff --git a/submit.puml b/submit.puml
index 08a2c98..07555d4 100644
--- a/submit.puml
+++ b/submit.puml
@@ -9,6 +9,6 @@ alt balance ok
   Api --> Employee : 200 OK
 else insufficient
   Svc --> Api : BalanceExceeded
-  Api --> Employee : 422
+  Api --> Employee : 422 ProblemDetails
 end
 @enduml

İki dosya da değişmiş. Reviewer olarak PNG'nin diff'inden ne öğreniyorsun? Değişiklik yalnız bir etiket mi, yoksa biri bir lifeline'ı da silmiş mi? Bir hafta sonra aynı diyagramı iki kişi farklı branch'lerde değiştirirse merge conflict'i hangi dosyada nasıl çözersin? Cevap yazının asıl konusu: diyagramın kaynağı metinse, diyagram da kod gibi diff'lenir, review edilir, merge edilir ve CI (Continuous Integration) içinde doğrulanır.

Neden Diagrams-as-Code?

Diagrams-as-code, diyagramı bir çizim aracında kutu sürükleyerek değil, bir metin dosyasında tarif edip araçla render etmektir. Seride şimdiye kadar çizdiğimiz her diyagram bir soruya cevap veriyordu; bu yazının sorusu farklı: o cevaplar altı ay sonra hâlâ doğru mu? Çizim aracında yapılmış bir diyagramın üç bilinen sorunu var. Dosya binary'dir, diff'i yoktur. Kodun yanında değil bir wiki sayfasında ya da birinin diskinde durur. Ve güncellemek ayrı bir iş olduğu için yapılmaz; diyagram bayatlar, bayat diyagram da hiç olmamasından daha zararlıdır.

Metin kaynaklı diyagramda bu üç sorun yer değiştirir. .puml dosyası kodun yanında, docs/diagrams/ altında durur; aynı PR'da kod ve diyagram birlikte değişir; reviewer yukarıdaki gibi tek satırlık bir diff görür. Bedeli de var: layout'u sen değil araç belirler. Martin Fowler'ın UmlAsSketch yazısında ayırdığı sketch ve blueprint modlarından bu yaklaşım "koda yakın blueprint"e oturur; beyaz tahtadaki hızlı eskiz için hâlâ kalem daha iyidir. Bu yazıda PlantUML'i, bir sonrakinde Mermaid ile Structurizr DSL'i (Domain-Specific Language) inceleyeceğiz.

PlantUML'i Yerelde Çalıştırmak

PlantUML tek bir jar dosyasıdır ve Java ister. Class, use case, state ve component diyagramlarının yerleşimini Graphviz'in dot programı hesaplar; sequence diyagramları ise Graphviz olmadan da çizilir. Graphviz'siz bir makinede --version çıktısı bunu açıkça söylüyor:

PlantUML version 1.2026.9 / 18d0aae [2026-10-17 08:25:10 UTC]
...
Error: Dot executable does not exist
Error: only sequence diagrams will be generated

macOS'ta brew install graphviz, Ubuntu'da apt-get install graphviz yeterli; jar PATH'teki dot'u bulur, bulamazsa GRAPHVIZ_DOT ortam değişkeninden okur. 1.2026.9'un yardım metni çift tireli, okunur seçenekler gösteriyor (--svg, --output-dir); eski tek tireli -tsvg ve -o da hâlâ çalışıyor. Günlük kullanılacak üç komut:

# Söz dizimini kontrol et, resim üretme (hata varsa exit code 200)
java -jar plantuml-1.2026.9.jar --check-syntax docs/diagrams

# Klasördeki tüm .puml dosyalarını SVG'ye çevir
java -jar plantuml-1.2026.9.jar --svg --output-dir "$PWD/out" "docs/diagrams/*.puml"

# Kontrol ve render'ı birlikte yap, ilk hatada dur
java -jar plantuml-1.2026.9.jar --svg --stop-on-error "docs/diagrams/*.puml"

Editörde canlı önizleme için Visual Studio Code'da (VS Code) jebbs'in PlantUML eklentisi, Rider ve diğer JetBrains IDE'lerinde (Integrated Development Environment) "PlantUML Integration" plugin'i yaygın. VS Code eklentisinin plantuml.render ayarı varsayılan olarak Local'dır, yani makinendeki Java ve Graphviz'le çizer; PlantUMLServer seçersen metni plantuml.server adresine gönderir. Bu ayrımın neden önemli olduğuna gizlilik bölümünde döneceğiz.

Serinin Diyagramları PlantUML'de

Seride çizdiğimiz diyagramların hepsinin bir PlantUML karşılığı var. Repo düzeni basit: her diyagram bir dosya, dosya adı diyagramın adı, ortak stil ayrı bir include dosyasında.

docs/diagrams/
    hr-style.iuml
    use-cases.puml
    domain-model.puml
    submit-leave-request.puml
    leave-request-states.puml
    containers.puml

Use case diagram'ı (serinin 3. yazısındaki model). Actor ile use case arasındaki association -- ile yönsüz çizilir; <<include>> ve <<extend>> ise kesikli ..> okudur ve yönü UML'deki gibi include eden use case'ten included olana, extend edenden base use case'e doğrudur:

@startuml use-cases
!include hr-style.iuml
title Leave module - use cases
left to right direction

actor "Employee" as Employee
actor "Manager" as Manager
actor "Director" as Director
actor "HR Specialist" as HR
actor "Calendar System" as Calendar <<system>>

Director -|> Manager

rectangle "HR Portal - Leave" {
  usecase "UC-01 Request Leave\n--\nextension points\nAttachment" as UC01
  usecase "UC-02 Decide on Leave Request" as UC02
  usecase "UC-03 Cancel Leave Request" as UC03
  usecase "UC-04 View Leave Balance" as UC04
  usecase "UC-05 Adjust Leave Balance" as UC05
  usecase "UC-06 Manage Leave Policies" as UC06
  usecase "Check Balance" as CheckBalance
  usecase "Attach Medical Report" as AttachReport
}

Employee -- UC01
Employee -- UC03
Employee -- UC04
Manager -- UC02
HR -- UC03
HR -- UC05
HR -- UC06
UC02 -- Calendar
UC03 -- Calendar

UC01 ..> CheckBalance : <<include>>
UC02 ..> CheckBalance : <<include>>
AttachReport ..> UC01 : <<extend>>
note right of AttachReport
  condition: leave type = SICK
  extension point: Attachment
end note
@enduml

Domain class diagram'ı. Multiplicity'ler association'ın uçlarına tırnak içinde yazılır, *-- composition (dolu elmas), --> navigable association, /RemainingDays derived attribute'tur. Department'tan direktöre giden ucun 0..1 olduğuna dikkat et; ER (Entity-Relationship) diagram yazısında zorunlu iki ilişkinin döngüsünü kırmak için bu ucu optional yapmıştık:

@startuml domain-model
!include hr-style.iuml
title Leave module - domain model
hide empty members

class Employee {
  EmployeeNumber : string
  FullName : string
  Email : string
}

class Department {
  Name : string
}

class LeaveRequest {
  Period : DateRange
  WorkingDays : int
  Reason : string [0..1]
  Status : LeaveStatus
  + Submit(workingDays : int, now : DateTimeOffset)
  + Approve(approver : Employee, comment : string [0..1], now : DateTimeOffset)
  + Reject(approver : Employee, comment : string, now : DateTimeOffset)
  + Cancel(today : DateOnly)
}

class Approval {
  Step : ApprovalStep
  Decision : ApprovalDecision
  Comment : string [0..1]
  DecidedAt : DateTimeOffset
}

class LeaveType {
  Code : string
  Name : string
  DeductsFromBalance : bool
}

class LeaveBalance {
  Year : int
  EntitledDays : int
  UsedDays : int
  /RemainingDays : int
}

class LeaveAttachment {
  FileName : string
  StoragePath : string
}

enum LeaveStatus {
  Draft
  PendingManagerApproval
  PendingDirectorApproval
  Approved
  Rejected
  Cancelled
}

Employee "0..*" --> "0..1" Employee : manager
Employee "0..*" --> "1" Department
Department "0..*" --> "0..1" Employee : director
LeaveRequest "0..*" --> "1" Employee : requester
LeaveRequest "0..*" --> "1" LeaveType
LeaveRequest *-- "0..1" LeaveAttachment
LeaveRequest "1" *-- "0..2" Approval : approvals
Approval "0..*" --> "1" Employee : approver
LeaveBalance "0..*" --> "1" Employee
LeaveBalance "0..*" --> "1" LeaveType
@enduml

Sequence diagram'ı, serinin 8. ve 9. yazılarındaki "talebi gönder" senaryosu. autonumber mesajları numaralar, activate/deactivate activation bar'ı çizer, alt/else/end combined fragment'tir:

@startuml submit-leave-request
!include hr-style.iuml
title UC-01 Submit leave request (R2, R3)
autonumber

actor "Employee" as Employee
participant "LeaveRequestForm\nComponent" as Form
participant "HrPortal.Api" as Api
participant "LeaveRequest\nService" as Service
participant "IWorkingDay\nCalculator" as Calc
participant "IBalance\nService" as Balance
database "HR Database" as Db

Employee -> Form : Submit
Form -> Api : POST /leave-requests/42/submit
activate Api
Api -> Service : SubmitAsync(42)
activate Service
Service -> Db : load LeaveRequest #42
Service -> Calc : CountWorkingDays(2026-12-21..25)
Calc --> Service : 5
Service -> Balance : HasEnoughBalanceAsync(E-1001, ANNUAL, 5)
Balance --> Service : true (remaining 8)
alt enough balance
  Service -> Service : request.Submit(5, now)
  Service -> Db : SaveChangesAsync()
  Service --> Api : PendingManagerApproval
  Api --> Form : 200 OK
else insufficient balance
  Service --> Api : BalanceExceeded
  Api --> Form : 422 ProblemDetails
end
deactivate Service
deactivate Api
@enduml

Bu dosyanın küçültülmüş bir versiyonu ve PlantUML'in ondan ürettiği resim yan yana:

State machine diagram'ı, 11. yazıdaki yaşam döngüsünün aynısı. Composite state state "..." as X { } bloğuyla, choice pseudostate <<choice>> stereotype'ıyla, entry ve after(...) davranışları state X : ... satırlarıyla yazılır:

@startuml leave-request-states
!include hr-style.iuml
title LeaveRequest lifecycle
hide empty description

[*] --> Draft
Draft --> PendingManagerApproval : Submit [hasEnoughBalance]

state "Pending Approval" as PendingApproval {
  state PendingManagerApproval : entry / notifyManager
  state PendingManagerApproval : after(2 working days) / remindApprover
  state PendingDirectorApproval : entry / notifyDirector
  state PendingDirectorApproval : after(2 working days) / remindApprover
  state afterManager <<choice>>
  PendingManagerApproval --> afterManager : Approve [hasEnoughBalance]
  afterManager --> PendingDirectorApproval : [requiresDirectorApproval]
}

afterManager --> Approved : [else]
PendingDirectorApproval --> Approved : Approve [hasEnoughBalance]
PendingApproval --> Rejected : Reject [hasComment] / recordApproval
PendingApproval --> Cancelled : Cancel
state Approved : entry / deductBalance; addCalendarEntry
Approved --> Cancelled : Cancel [!leaveStarted || byHrSpecialist] / refundBalance; removeCalendarEntry
@enduml

Ortak Stil: !include, skinparam ve style

Beş diyagramın her birine font, köşe yuvarlaklığı ve not rengi yazmak yerine ortak ayarları tek dosyaya koyup !include ile çağırıyoruz:

skinparam shadowing false
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam roundCorner 8
<style>
title {
  FontSize 16
  FontStyle bold
}
note {
  BackgroundColor #FFF8DC
}
</style>

İki stil mekanizması yan yana duruyor. skinparam eski ve hâlâ çalışan yöntem; PlantUML dokümantasyonu yeni diyagramlar için CSS'e (Cascading Style Sheets) benzeyen <style> bloğunu öneriyor ve eski diyagramların gelecek sürümlerde de çalışmaya devam edeceğini söylüyor. Yeni bir repo başlatıyorsan stili <style> ile yaz, elindeki skinparam'ları acele etmeden taşı.

Include dosyasının uzantısı bilinçli olarak .iuml. İlk denemede dosyanın adı hr-style.puml idi ve "docs/diagrams/*.puml" glob'u onu da render etmeye çalıştı: Warning: no image in docs/diagrams/hr-style.puml. Uyarı zararsız görünür ama CI log'unu kirletir; parça dosyalarını ayrı bir uzantıyla tutmak glob'u temiz bırakıyor. !include yolu, include eden dosyanın klasörüne göre çözülür; birden fazla diyagram setinde aynı stili kullanacaksan plantuml.include.path Java property'siyle ortak bir arama yolu tanımlayabilirsin. !include bir URL (Uniform Resource Locator) de alabilir, ama derlemenin internete bağımlı olması ve başkasının dosyasının değişebilmesi iki ayrı risk; ortak stili repo'da tut.

C4-PlantUML: Standart Kütüphaneden C4 Diyagramı

C4 (Context, Containers, Components, Code) diyagramları için PlantUML'in kendisinde bir notasyon yok; onu C4-PlantUML kütüphanesi sağlıyor ve bu kütüphane PlantUML'in standart kütüphanesine (stdlib) gömülü geliyor. java -jar plantuml.jar -stdlib çıktısına göre 1.2026.9'un içindeki sürüm 2.14.0. İnternetten include etmeye gerek yok, <C4/C4_Container> köşeli parantezli yazımla jar'ın içinden okunuyor:

@startuml containers
!include <C4/C4_Container>
!include hr-style.iuml
title HR Portal - containers

Person(employee, "Employee", "Requests leave")
Person(manager, "Manager", "Approves or rejects")
System_Ext(calendar, "Calendar System", "Corporate calendar")
System_Ext(mail, "E-mail Server", "SMTP relay")

System_Boundary(hr, "HR Portal") {
  Container(web, "Web App", "Angular 22", "Single-page app")
  Container(api, "HrPortal.Api", "ASP.NET Core, .NET 10", "Leave, Payroll, Notification modules")
  Container(worker, "HrPortal.Worker", ".NET 10 worker", "Notifications and approval reminders")
  ContainerDb(db, "HR Database", "SQL Server", "Requests, balances, approvals")
  ContainerDb(cache, "Cache", "Redis", "Public holidays")
  ContainerQueue(broker, "Message Broker", "Azure Service Bus", "leave-events topic")
}

Rel(employee, web, "Creates and submits leave requests", "HTTPS")
Rel(manager, web, "Approves or rejects requests", "HTTPS")
Rel(web, api, "Calls", "JSON/HTTPS")
Rel(api, db, "Reads from and writes to", "EF Core")
Rel(api, cache, "Caches holidays in", "RESP")
Rel(api, broker, "Publishes LeaveRequestApproved etc.", "AMQP")
Rel(api, calendar, "Adds and removes leave entries", "HTTPS")
Rel(broker, worker, "Delivers events to", "AMQP")
Rel(worker, mail, "Sends e-mails via", "SMTP")
SHOW_LEGEND()
@enduml

Macro'lar 14. yazıdaki notation checklist'ini neredeyse kendiliğinden uygular: her elemanın tipi (Container, ContainerDb, ContainerQueue), teknolojisi ve kısa açıklaması var; her Rel tek yönlü ve etiketli; SHOW_LEGEND() legend'ı ekliyor. Container listesi 13. yazının deployment diyagramıyla aynı: API (Application Programming Interface), worker, veritabanı (SQL Server), Redis ve Azure Service Bus. C4'ü UML'den ayıran şey de burada görünüyor: kutunun şekli değil, içindeki "[Container: ASP.NET Core, .NET 10]" bilgisi anlam taşıyor.

CI'da Kontrol ve Render

Diyagram kaynağı repo'ya girince bir sonraki adım, onu her PR'da doğrulamak. GitHub Actions'ta PlantUML için ayrı bir action'a gerek yok; Java'yı kur, Graphviz'i kur, jar'ı sabit bir sürümle indir ve iki komutu çalıştır:

name: diagrams

on:
  pull_request:
    paths:
      - "docs/diagrams/**"

jobs:
  render:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-java@v6
        with:
          distribution: temurin
          java-version: "21"

      - name: Install Graphviz
        run: sudo apt-get update && sudo apt-get install -y graphviz

      - name: Download PlantUML
        run: curl -fsSL -o plantuml.jar https://github.com/plantuml/plantuml/releases/download/v1.2026.9/plantuml-1.2026.9.jar

      - name: Check syntax
        run: java -jar plantuml.jar --check-syntax docs/diagrams

      - name: Render SVG
        run: java -jar plantuml.jar --svg --output-dir "$PWD/out" "docs/diagrams/*.puml"

      - uses: actions/upload-artifact@v7
        with:
          name: diagrams
          path: out/

Workflow'un iki adımını yerelde aynı jar'la çalıştırdım: --check-syntax exit code 0 döndü ve out/ altında beş SVG (Scalable Vector Graphics) oluştu. Workflow'un kendisini GitHub üzerinde koşturmadım; action sürümleri yazım tarihindeki son major sürümler. Bir syntax hatası nasıl görünüyor? else yerine els yazılmış bir dosya:

Error line 5 in file: broken/typo.puml
Some diagram description contains errors

Exit code 200'dür ve job kırmızıya döner. --output-dir için bir ayrıntı: göreli bir yol verirsen (out), PlantUML onu her kaynak dosyanın kendi klasörüne göre çözer ve SVG'ler docs/diagrams/out/ altına düşer. Workflow'da bu yüzden "$PWD/out" gibi mutlak yol kullandık.

Üretilen SVG'leri commit'lemek mi, artifact olarak bırakmak mı? Aynı makinede aynı jar ve aynı Graphviz'le iki kez render ettiğimde dosyalar bayt bayt aynıydı. Ama geliştiricinin Graphviz'i ile CI'daki Graphviz farklı sürümse çıktı da farklı olabilir ve "SVG güncel mi?" kontrolü kendi kendine kırmızıya döner. Pratik kural: kaynak commit'lenir, resim CI'da üretilir. README'de resim göstermek zorundaysan render'ı yalnız main branch'te çalışan bir job'a ver.

Gizlilik: Public Sunucu ve SVG'nin İçindeki Kaynak

PlantUML'in herkese açık bir render sunucusu var ve bazı wiki eklentileri, editör ayarları ve Markdown önizleyicileri bu adresi kullanacak şekilde yapılandırılabiliyor ya da onunla geliyor. Sunucu diyagramı URL'den okur: PlantUML'in "text encoding" sayfası metnin Unicode (UTF-8) olarak alınıp Deflate ile sıkıştırıldığını ve base64'e benzeyen bir alfabeyle URL'ye yazıldığını anlatır. Yani sıkıştırılmış ama şifrelenmemiş diyagram metninin tamamı o sunucuya gider. Container diyagramındaki "HrPortal.Worker", "leave-events topic", veritabanı adları ve iç servisler şirket dışına çıkmış olur. Kural basit: mimari diyagramları yerel jar'la ya da kendi altyapında çalışan bir PlantUML sunucusuyla render et; editör eklentisinde render modunun Local olduğunu kontrol et.

İkinci ayrıntı daha az bilinir: PlantUML ürettiği SVG ve PNG'ye kaynağı da gömer. SVG'nin içinde <?plantuml-src ...?> diye bir işlem talimatı var ve --extract-source onu geri açar:

$ java -jar plantuml.jar --extract-source submit-leave-request.svg
------------------------
submit-leave-request.svg

@startuml
!include hr-style.iuml
title UC-01 Submit leave request (R2, R3)
autonumber
...

Bu çoğu zaman bir özellik, çünkü elinde sadece resim kalmışsa kaynağı geri alabilirsin. Ama "yalnız resmi paylaşıyorum" dediğin anda metni de paylaşmış olursun. Dışarıya verilecek resimler için PlantUML'in --obfuscate seçeneği metinleri anlamsız string'lerle değiştiriyor; ya da resmi PlantUML dışı bir araçla PNG'ye dönüştürüp metadata'sız gönderebilirsin.

Sık Düşülen Tuzaklar

Türkçe locale'de stdlib include'unun kırılması. Bu yazıyı hazırlarken C4 diyagramı ilk denemede render olmadı. Makinenin dil ayarı Türkçe olduğu için JVM (Java Virtual Machine) tr_TR locale'iyle açılıyor ve PlantUML stdlib'deki bir dosya adını küçük harfe çevirirken INFO, Türkçe kurala göre ınfo oluyor:

java.io.UncheckedIOException: java.io.FileNotFoundException: stdlib/c4/ınfo.spm (No such file or directory)
Error line 2 in file: containers.puml
Some diagram description contains errors

Exit code 200. Yazılımcıların "Turkish I problem" dediği klasik hata: locale'e duyarlı toLowerCase dosya adında kullanılınca noktasız ı üretiyor. Çözüm JVM'i İngilizce locale'le açmak; ortam değişkeni hem komut satırını hem de Java'yı arka planda çağıran editör eklentilerini kapsar:

export JAVA_TOOL_OPTIONS="-Duser.language=en -Duser.country=US"
java -jar plantuml-1.2026.9.jar --svg containers.puml

Aynı dosya bu ayarla hatasız render ediliyor. Ubuntu runner'larında JVM Türkçe locale'le açılmadığı için hata CI'da görünmez, yalnız Türkçe makinelerde patlar; "bende çalışmıyor" şikâyetinin kaynağını bilmek saatler kazandırır.

Association class'ı yanlış ilişkiye bağlamak. Domain modelin ilk taslağında Approval'ı (LeaveRequest, Employee) .. Approval söz dizimiyle association class olarak çizdim. Render sonucu, kesikli çizgiyi talep sahibini gösteren requester ilişkisinin üzerine koydu; çünkü aynı iki class arasında iki farklı ilişki vardı ve PlantUML hangisini kastettiğimi bilemezdi. Söz dizimi geçerliydi, --check-syntax sessizdi, diyagram ise yanlıştı. Bu yüzden yukarıdaki modelde Approval'ı composition ve ayrı bir approver association'ıyla çizdik. Ders genel: syntax kontrolü anlamı kontrol etmez, render'a bakmadan merge etme.

Layout'la kavga etmek. Bir kutuyu sağa almak için gizli oklar (-[hidden]->) ve yön ipuçları eklemek mümkün, ama her biri diyagramı bir sonraki değişiklikte daha kırılgan yapar. Okunmuyorsa çoğu zaman diyagram çok şey anlatmaya çalışıyordur; ikiye böl.

Bütün solution'ı tek diyagrama dökmek. Koddan üretilen dev class diagram'lar (serinin 6. yazısındaki puml-gen tartışması) review edilemez. Diyagram başına bir soru kuralı diagrams-as-code'da da geçerli.

Public sunucuya varsayılan olarak gitmek. Yukarıda anlattığımız gibi; özellikle Confluence ve wiki eklentilerinin ayarlarına bak.

Küçük Bir Deneme

★☆☆ Yazıdaki beş dosyayı kendi makinende docs/diagrams/ altına koy, --check-syntax ve --svg ile render et. Sonra hr-style.iuml'deki skinparam satırlarını <style> bloğuna taşı ve çıktının değişmediğini SVG'leri karşılaştırarak doğrula.

★★☆ Sequence diagram'a, 9. yazıdaki gibi direktör onayını gösteren bir opt [WorkingDays > 3] fragment'i ve par ile paralel bildirim + takvim adımları ekle. Değişikliği bir branch'te yap ve git diff'in reviewer'a ne anlattığını yorumla.

★★★ Workflow'a, PR'daki değişen .puml dosyalarının render'ını PR yorumuna ekleyen bir adım yaz (ipucu: git diff --name-only ve SVG'yi artifact'e koyan adım). Ardından aynı işi public sunucuya gitmeden yaptığını kanıtla: job'u ağ erişimi yalnız GitHub'a açık bir ortamda çalıştırdığını varsay ve hangi adımın internete çıktığını listele.

Bir sonraki yazıda diyagramı ayrı bir dosya olarak değil, doğrudan Markdown'ın içinde yazmayı deneyeceğiz: GitHub ve Azure DevOps'un kendisinin render ettiği Mermaid, ve diyagramları tek bir modelden türeten Structurizr DSL. Aynı container diyagramını iki araçla çizip hangisini ne zaman seçeceğimizi karşılaştıracağız.