Mattermost Kurulumu, Zoom Entegrasyonu ve CI/CD Pipeline Bildirimleri

Birçok büyük şirket, veri güvenliği ve uyumluluk gerekçeleriyle mesajlaşma altyapısını kendi kontrolünde (self-hosted) tutmak istiyor. Slack veya Discord yerine Mattermost gibi açık kaynaklı, kurum içinde barındırılabilen bir çözüm bu ihtiyacı karşılıyor. Bu yazıda Mattermost'u Docker ile nasıl ayağa kaldırdığımı, Zoom entegrasyonunu nasıl kurgulayacağımı ve CI/CD pipeline'ından doğrudan bildirim almayı nasıl sağladığımı anlatıyorum.

Neden Mattermost?

Discord ve Slack, kurulum kolaylığı açısından harika ama kurumsal ortamda genelde iki soru sorulur: "Verimiz nerede tutuluyor?" ve "Bunu kendi altyapımıza entegre edebilir miyiz?" Mattermost, kaynak kodu açık olduğu ve kendi sunucunda barındırılabildiği için bu iki soruya da net cevap verebiliyor.

Kurulum: Docker Compose ile

Mattermost'un resmi docker reposu, PostgreSQL ve Mattermost sunucusunu ayrı container'larda çalıştıran modüler bir yapı sunuyor:

git clone https://github.com/mattermost/docker
cd docker
cp env.example .env
docker compose -f docker-compose.yml -f docker-compose.without-nginx.yml up -d

Burada dikkat edilmesi gereken bir nokta var: varsayılan docker-compose.yml, Mattermost portunu (8065) host makineye doğrudan açmıyor — bunun yerine bir nginx reverse proxy container'ı üzerinden trafiği yönlendirmeyi bekliyor. Local geliştirme/test aşamasında nginx'e ihtiyaç yoksa, docker-compose.without-nginx.yml dosyasını ek olarak vererek portu doğrudan host'a açmak en pratik yöntem.

Local geliştirme sırasında Zoom ve GitHub'ın localhost'a erişemediğini unutmamak gerekiyor — bunun için ngrok ile geçici bir public tünel açtım. Production'da bu servis bir VPS ya da AWS instance'ında sabit bir domain arkasında çalışacak.

Zoom Entegrasyonu

Mattermost'un resmi Zoom plugin'i, kanal içinden /zoom start komutuyla direkt görüşme başlatmayı sağlıyor. Kurulum şu adımlardan oluşuyor:

1. Mattermost tarafında System Console → Plugins → Marketplace üzerinden Zoom plugin'ini etkinleştirmek.
2. Zoom App Marketplace'te bir OAuth tipi uygulama oluşturmak (Zoom, eski JWT tipi entegrasyonları kaldırdığı için artık OAuth zorunlu).
3. Redirect URL'i Mattermost'un public adresine göre ayarlamak: https://SITEURL/plugins/zoom/oauth2/complete.
4. Zoom'dan alınan Client ID/Secret'ı Mattermost'un Zoom plugin ayarlarına girmek.

Bu adım, bir self-hosted aracın dış bir SaaS servisiyle (Zoom) nasıl güvenli şekilde (OAuth üzerinden, secret'lar şifrelenmiş halde) entegre olabileceğini gösteren iyi bir örnek.

CI/CD Pipeline Bildirimleri: Doğrudan GitHub Actions'tan

İlk denemede, GitHub webhook event'lerini dinleyip yorumlayan bir Flask servisi kurmuştum (Discord bot projesindeki gibi). Ancak CI/CD pipeline'ının kendi sonucunu bildirmek istediğimde, bu yaklaşımın gereksiz bir dolambaç olduğunu fark ettim: pipeline zaten "başarılı mı, başarısız mı" bilgisini elinde tutuyor, buna dışarıdan tekrar webhook event'i yorumlayarak ulaşmaya gerek yok.

Bunun yerine, GitHub Actions workflow'unun sonuna doğrudan Mattermost'a curl ile istek atan bir adım ekledim:

notify:
  needs: [deploy-job]
  if: always()
  runs-on: ubuntu-latest
  steps:
    - name: Notify Mattermost - Success
      if: needs.deploy-job.result == 'success'
      run: |
        curl -X POST -H 'Content-Type: application/json' \
        -d '{
          "text": "✅ **Deploy Başarılı** — `repo-adi`\n**Branch:** main\n**Commit:** `${{ github.sha }}`\n**Yapan:** ${{ github.actor }}"
        }' \
        "${{ secrets.MATTERMOST_WEBHOOK_URL }}"

Bu yöntemin webhook dinleyiciye göre iki net avantajı var:

• Daha az hareketli parça: Ayrı bir servisin (Flask + ngrok/public URL) sürekli ayakta olmasına gerek yok.
• Daha doğru bilgi kaynağı: Pipeline'ın kendisi "başarılı/başarısız" kararını verdiği an bunu bildiriyor; dışarıdan farklı event tiplerini (workflow_run, check_run vb.) ayıklayıp yorumlamaya gerek kalmıyor.

Öğrendiklerim

• "Event dinlemek" her zaman en doğru yaklaşım değil. Bazen kaynağın (burada CI/CD pipeline'ının) doğrudan bildirimi tetiklemesi, dışarıdan event'leri yorumlamaya çalışmaktan daha sağlam ve daha az bakım gerektiren bir çözüm.
• Self-hosted araçların varsayılan yapılandırmaları farklılık gösterebiliyor — Mattermost'un nginx'siz/nginx'li docker-compose varyasyonları gibi, bir aracı production'a taşımadan önce hangi bileşenlerin gerçekten gerekli olduğunu anlamak önemli.
• OAuth tabanlı entegrasyonlar, JWT gibi eski yöntemlere göre artık standart — üçüncü parti bir SaaS aracını (Zoom gibi) bağlarken güncel kimlik doğrulama yöntemini kontrol etmek gerekiyor.

---

Bu yazı, aynı otomasyon prensiplerinin Discord üzerinde nasıl uygulandığını anlatan önceki yazımın devamı niteliğindedir.