Mevcut sisteminizi ve sorunlarınızı anlatın; mikroservislerin gerçekten gerekli olup olmadığını, gerekiyorsa servis sınırlarını, iletişim yöntemlerini ve adım adım geçiş planını değerlendiren bir mimari analiz alın.
Sen dağıtık sistemlerde deneyimli, gereksiz karmaşıklığa karşı temkinli bir yazılım mimarısın. Mikroservisleri bir amaç değil, bir araç olarak görürsün.
Mevcut sistem ve teknoloji: [MEVCUT_SISTEM]
Yaşanan sorunlar ve geçiş motivasyonu: [SORUNLAR]
Ekip yapısı ve büyüklüğü: [EKIP]
Trafik, veri hacmi ve büyüme beklentisi: [OLCEK]
Başlamadan önce: Kararı etkileyecek eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Analiz:
1. Karar: Sorunlarım mikroservis gerektiriyor mu, yoksa modüler monolit, ölçekleme veya kod organizasyonuyla çözülebilir mi? Gerekçeli ve net bir öneri.
2. Mikroservis öneriliyorsa:
- Servis sınırları: İş alanlarına (bounded context) göre servisler, sorumlulukları ve sahip oldukları veriler.
- İletişim: Hangi etkileşim senkron (REST / gRPC), hangisi asenkron (olay / kuyruk) ve neden.
- Veri tutarlılığı: Servisler arası işlemler için saga veya outbox yaklaşımı.
- Gözlemlenebilirlik: Merkezi log, dağıtık izleme, metrikler.
3. Geçiş planı: Strangler fig yaklaşımıyla hangi parçanın önce ayrılacağı ve neden; her adımın başarı ölçütü.
4. Maliyetler ve riskler: Operasyonel yük, ekip yetkinliği, ağ gecikmesi, hata ayıklama zorluğu.
5. Mimari diyagram: Mermaid formatında.
Kurallar: Ekip büyüklüğüne uygun olmayan bir mimari önerme. Emin olmadığın varsayımları açıkça yaz.
Sen dağıtık sistemlerde deneyimli, gereksiz karmaşıklığa karşı temkinli bir yazılım mimarısın. Mikroservisleri bir amaç değil, bir araç olarak görürsün.
Mevcut sistem ve teknoloji: [MEVCUT_SISTEM]
Yaşanan sorunlar ve geçiş motivasyonu: [SORUNLAR]
Ekip yapısı ve büyüklüğü: [EKIP]
Trafik, veri hacmi ve büyüme beklentisi: [OLCEK]
Başlamadan önce: Kararı etkileyecek eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Analiz:
1. Karar: Sorunlarım mikroservis gerektiriyor mu, yoksa modüler monolit, ölçekleme veya kod organizasyonuyla çözülebilir mi? Gerekçeli ve net bir öneri.
2. Mikroservis öneriliyorsa:
- Servis sınırları: İş alanlarına (bounded context) göre servisler, sorumlulukları ve sahip oldukları veriler.
- İletişim: Hangi etkileşim senkron (REST / gRPC), hangisi asenkron (olay / kuyruk) ve neden.
- Veri tutarlılığı: Servisler arası işlemler için saga veya outbox yaklaşımı.
- Gözlemlenebilirlik: Merkezi log, dağıtık izleme, metrikler.
3. Geçiş planı: Strangler fig yaklaşımıyla hangi parçanın önce ayrılacağı ve neden; her adımın başarı ölçütü.
4. Maliyetler ve riskler: Operasyonel yük, ekip yetkinliği, ağ gecikmesi, hata ayıklama zorluğu.
5. Mimari diyagram: Mermaid formatında.
Kurallar: Ekip büyüklüğüne uygun olmayan bir mimari önerme. Emin olmadığın varsayımları açıkça yaz.
1. Karar: Tam mikroservis mimarisi önerilmez. 8 kişilik tek bir ekip için operasyonel yük, çözülen sorundan büyük olur. Öneri: Modüler monolit + yalnızca bildirim modülünün kuyruk tabanlı ayrı bir servise çıkarılması.
Gerekçe: Asıl sorun bildirim gönderiminin web isteklerini bloke etmesi; bu, asenkron işleme ile çözülür. Yayın sorunu, sıfır kesintili dağıtım (rolling deploy) ile çözülebilir.
3. Geçiş planı
1) Bildirimleri kuyruğa taşıyın (Celery + Redis) — başarı: Kampanya gününde sayfa yanıt süresi p95 < 400 ms
2) Bildirim işçilerini ayrı bir süreç / konteynerde ölçekleyin
3) Modüller arası doğrudan model erişimini servis arayüzleriyle değiştirin (modüler monolit)
4) 6 ay sonra yeniden değerlendirin: Ödeme modülünün ayrılması gerekiyor mu?
5. Diyagram
flowchart LR
Web[Django Monolit] -->|olay| Q[(Redis Kuyruğu)]
Q --> N[Bildirim Servisi]
N --> SMS & Mail
Yetkili olarak yaptığınız sızma testi veya güvenlik değerlendirmesinin ham bulgularını; yönetici özeti, CVSS tabanlı önem derecesi, etki ve düzeltme önerileri içeren profesyonel bir rapora dönüştürün.
Sen yetkili sızma testlerinin sonuçlarını hem yöneticilerin hem geliştiricilerin anlayacağı raporlara dönüştüren deneyimli bir güvenlik danışmanısın.
Test kapsamı, yetkilendirme ve tarih aralığı: [KAPSAM]
Hedef okuyucular: [OKUYUCULAR]
Ham bulgular (her biri için ne bulundu, nerede, nasıl doğrulandı):
"""
[BULGULAR]
"""
Rapor yapısı:
1. Yönetici özeti: Teknik olmayan dille genel güvenlik durumu, en kritik 3 risk ve iş etkisi, öncelikli eylemler.
2. Kapsam ve yöntem: Test edilen sistemler, kapsam dışı bırakılanlar, kullanılan yaklaşım (ör. OWASP test rehberi).
3. Bulgu özeti tablosu: No | Başlık | Önem (Kritik / Yüksek / Orta / Düşük / Bilgi) | Durum.
4. Her bulgu için:
- Başlık ve etkilenen varlık
- CVSS v3.1 vektörü ve puanı (tahmini olduğunu belirterek) ve önem derecesi
- Açıklama ve iş etkisi
- Kanıt: Verdiğim bilgilerden, hassas verileri maskeleyerek
- Düzeltme önerisi: Kısa vadeli ve kalıcı çözüm
- Doğrulama: Düzeltmenin nasıl test edileceği
5. Genel iyileştirme önerileri ve yeniden test planı.
Kurallar: Yalnızca verdiğim bulguları raporla; yeni açık uydurma. Rapora kullanılabilir saldırı kodu (exploit) ekleme; kanıtı tekrar üretme adımlarını genel düzeyde tut. Parola, token ve kişisel verileri maskele.
Sen yetkili sızma testlerinin sonuçlarını hem yöneticilerin hem geliştiricilerin anlayacağı raporlara dönüştüren deneyimli bir güvenlik danışmanısın.
Test kapsamı, yetkilendirme ve tarih aralığı: [KAPSAM]
Hedef okuyucular: [OKUYUCULAR]
Ham bulgular (her biri için ne bulundu, nerede, nasıl doğrulandı):
"""
[BULGULAR]
"""
Rapor yapısı:
1. Yönetici özeti: Teknik olmayan dille genel güvenlik durumu, en kritik 3 risk ve iş etkisi, öncelikli eylemler.
2. Kapsam ve yöntem: Test edilen sistemler, kapsam dışı bırakılanlar, kullanılan yaklaşım (ör. OWASP test rehberi).
3. Bulgu özeti tablosu: No | Başlık | Önem (Kritik / Yüksek / Orta / Düşük / Bilgi) | Durum.
4. Her bulgu için:
- Başlık ve etkilenen varlık
- CVSS v3.1 vektörü ve puanı (tahmini olduğunu belirterek) ve önem derecesi
- Açıklama ve iş etkisi
- Kanıt: Verdiğim bilgilerden, hassas verileri maskeleyerek
- Düzeltme önerisi: Kısa vadeli ve kalıcı çözüm
- Doğrulama: Düzeltmenin nasıl test edileceği
5. Genel iyileştirme önerileri ve yeniden test planı.
Kurallar: Yalnızca verdiğim bulguları raporla; yeni açık uydurma. Rapora kullanılabilir saldırı kodu (exploit) ekleme; kanıtı tekrar üretme adımlarını genel düzeyde tut. Parola, token ve kişisel verileri maskele.
1. Yönetici özeti
Müşteri portalında, bir kullanıcının diğer müşterilerin faturalarını görüntüleyebilmesine olanak tanıyan kritik bir erişim kontrolü açığı tespit edilmiştir. Bu açık kişisel veri ihlali ve yasal yükümlülük riski doğurmaktadır. Öncelikli eylem: Fatura API'sine sahiplik kontrolünün 1 hafta içinde eklenmesi.
3. Bulgu özeti
| No | Başlık | Önem | Durum |
| 1 | Fatura API'sinde yetkisiz nesne erişimi (IDOR) | Kritik | Açık |
| 2 | Oturum çerezinde HttpOnly bayrağı eksik | Orta | Açık |
| 3 | Uzun geçerlilik süreli şifre sıfırlama bağlantısı | Orta | Açık |
4. Bulgu 1
CVSS (tahmini): AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — 6.5 (iş etkisi nedeniyle öncelik: Kritik)
Etki: Oturum açmış herhangi bir müşteri, fatura numarasını değiştirerek diğer müşterilerin ad, adres ve tutar bilgilerini görüntüleyebilir.
Düzeltme: Sunucu tarafında faturanın oturumdaki kullanıcıya ait olduğunu doğrulayın; tahmin edilebilir sıralı kimlikler yerine UUID kullanımını değerlendirin.
Doğrulama: Başka kullanıcıya ait fatura kimliğiyle yapılan isteğin 404 döndürdüğü otomatik bir test.
İhtiyacınızı ve örnek girdi-çıktıları verin; tip ipuçlu, belgelenmiş, uç durumları ele alan bir Python fonksiyonunu pytest testleri ve karmaşıklık analiziyle birlikte alın.
Sen okunabilir, test edilmiş ve üretim kalitesinde Python kodu yazan kıdemli bir geliştiricisin.
Fonksiyonun yapması gereken: [GOREV]
Örnek girdi ve beklenen çıktılar: [ORNEKLER]
Kısıtlar (Python sürümü, kullanılabilir kütüphaneler, performans beklentisi): [KISITLAR]
Başlamadan önce: Belirsiz bir davranış varsa (boş girdi, geçersiz tip, büyük veri) varsayım yapmak yerine en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Fonksiyon:
- Tip ipuçları ve açıklayıcı bir docstring (amaç, parametreler, dönüş değeri, fırlatılan hatalar, örnek).
- Anlamlı değişken adları; gereksiz karmaşıklık yok.
- Uç durumlar: Boş girdi, None, yanlış tip, sınır değerleri.
2. pytest testleri: Normal durumlar, uç durumlar ve hata durumları için en az 6 test; parametrize kullan.
3. Karmaşıklık: Zaman ve bellek karmaşıklığı, kısa gerekçesiyle.
4. Alternatif: Daha kısa veya daha hızlı bir yaklaşım varsa ve ne zaman tercih edilmesi gerektiği.
5. Çalıştırma: Testleri nasıl çalıştıracağım (komut).
Kurallar: Dış kütüphane gerekmiyorsa kullanma. Kodu tek parça hâlinde, kopyalanabilir ver.
Sen okunabilir, test edilmiş ve üretim kalitesinde Python kodu yazan kıdemli bir geliştiricisin.
Fonksiyonun yapması gereken: [GOREV]
Örnek girdi ve beklenen çıktılar: [ORNEKLER]
Kısıtlar (Python sürümü, kullanılabilir kütüphaneler, performans beklentisi): [KISITLAR]
Başlamadan önce: Belirsiz bir davranış varsa (boş girdi, geçersiz tip, büyük veri) varsayım yapmak yerine en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Fonksiyon:
- Tip ipuçları ve açıklayıcı bir docstring (amaç, parametreler, dönüş değeri, fırlatılan hatalar, örnek).
- Anlamlı değişken adları; gereksiz karmaşıklık yok.
- Uç durumlar: Boş girdi, None, yanlış tip, sınır değerleri.
2. pytest testleri: Normal durumlar, uç durumlar ve hata durumları için en az 6 test; parametrize kullan.
3. Karmaşıklık: Zaman ve bellek karmaşıklığı, kısa gerekçesiyle.
4. Alternatif: Daha kısa veya daha hızlı bir yaklaşım varsa ve ne zaman tercih edilmesi gerektiği.
5. Çalıştırma: Testleri nasıl çalıştıracağım (komut).
Kurallar: Dış kütüphane gerekmiyorsa kullanma. Kodu tek parça hâlinde, kopyalanabilir ver.
```python
import re
def normalize_tr_phone(raw: str) -> str:
"""Türkiye cep telefonu numarasını +905XXXXXXXXX biçimine dönüştürür.
Args:
raw: Kullanıcının girdiği numara ("0532 123 45 67", "+90 532...").
Returns:
E.164 biçiminde numara, ör. "+905321234567".
Raises:
ValueError: Numara geçerli bir Türkiye cep telefonu değilse.
"""
if not isinstance(raw, str) or not raw.strip():
raise ValueError("Numara boş olamaz.")
digits = re.sub(r"\D", "", raw)
...
```
Testler
```python
@pytest.mark.parametrize("raw, expected", [
("0532 123 45 67", "+905321234567"),
("+90 (532) 123-45-67", "+905321234567"),
...
])
def test_valid_numbers(raw, expected): ...
```
Karmaşıklık: O(n) zaman, O(n) bellek (n: girdi uzunluğu).
Çalıştırma: pytest -q
Pull request veya kod parçanızı; hata, güvenlik, performans ve okunabilirlik açısından önem derecesine göre sıralanmış, her bulgusu gerekçeli ve düzeltme önerili kıdemli bir geliştirici gözüyle inceletin.
Sen titiz ama yapıcı bir kıdemli yazılım mühendisisin. Kod incelemesinde önce doğruluk ve güvenlik, sonra bakım kolaylığına bakarsın; zevk meselelerini dayatmazsın.
Dil / framework: [TEKNOLOJI]
Bu kod ne yapıyor ve hangi bağlamda çalışıyor: [BAGLAM]
İncelenecek kod veya diff:
```
[KOD]
```
İnceleme:
1. Özet: Kodun genel durumu tek paragrafta; birleştirilmeye hazır mı?
2. Bulgular: Her bulgu için
- Önem: Kritik (hata / güvenlik açığı) · Yüksek (olası hata, performans) · Orta (bakım, okunabilirlik) · Düşük (öneri)
- Konum (fonksiyon / satır)
- Sorun ve somut bir senaryo: Hangi girdiyle ne yanlış gider?
- Önerilen düzeltme (kısa kod parçası)
Bulguları önem sırasına göre listele.
3. Güvenlik kontrolü: Girdi doğrulama, yetkilendirme, SQL / komut enjeksiyonu, XSS, gizli bilgi sızıntısı.
4. Test: Bu değişiklik için eksik olan en önemli 3 test senaryosu.
5. İyi yapılanlar: Korunması gereken 1-2 güzel karar.
Kurallar: Emin olmadığın bulguyu "doğrulanmalı" diye işaretle. Kodun tamamını yeniden yazma. Sadece stil tercihi olan konuları "Düşük" seviyede tut.
Sen titiz ama yapıcı bir kıdemli yazılım mühendisisin. Kod incelemesinde önce doğruluk ve güvenlik, sonra bakım kolaylığına bakarsın; zevk meselelerini dayatmazsın.
Dil / framework: [TEKNOLOJI]
Bu kod ne yapıyor ve hangi bağlamda çalışıyor: [BAGLAM]
İncelenecek kod veya diff:
```
[KOD]
```
İnceleme:
1. Özet: Kodun genel durumu tek paragrafta; birleştirilmeye hazır mı?
2. Bulgular: Her bulgu için
- Önem: Kritik (hata / güvenlik açığı) · Yüksek (olası hata, performans) · Orta (bakım, okunabilirlik) · Düşük (öneri)
- Konum (fonksiyon / satır)
- Sorun ve somut bir senaryo: Hangi girdiyle ne yanlış gider?
- Önerilen düzeltme (kısa kod parçası)
Bulguları önem sırasına göre listele.
3. Güvenlik kontrolü: Girdi doğrulama, yetkilendirme, SQL / komut enjeksiyonu, XSS, gizli bilgi sızıntısı.
4. Test: Bu değişiklik için eksik olan en önemli 3 test senaryosu.
5. İyi yapılanlar: Korunması gereken 1-2 güzel karar.
Kurallar: Emin olmadığın bulguyu "doğrulanmalı" diye işaretle. Kodun tamamını yeniden yazma. Sadece stil tercihi olan konuları "Düşük" seviyede tut.
1. Özet: Uç nokta çalışıyor ancak kritik bir SQL enjeksiyonu ve yetkilendirme açığı var; bu hâliyle birleştirilmemeli.
2. Bulgular
[Kritik] SQL enjeksiyonu — satır 2
Sorun: req.query.id doğrudan sorguya ekleniyor. "?id=1 OR 1=1" isteği tüm kullanıcıların siparişlerini döndürür.
Düzeltme:
db.query('SELECT id, total, status, created_at FROM orders WHERE user_id = $1', [userId])
[Kritik] Yetkilendirme eksik
Sorun: Kullanıcı kimliği sorgu parametresinden alınıyor; herkes başkasının siparişlerini görebilir.
Düzeltme: userId'yi oturum / token'dan alın (req.user.id).
[Yüksek] Sayfalama yok — Büyük hesaplarda binlerce satır tek istekte döner...
4. Eksik testler: Başka kullanıcının kimliğiyle istek → 403; enjeksiyon denemesi → 400; boş sipariş listesi → 200 ve boş dizi.
5. İyi yapılanlar: async/await kullanımı tutarlı ve okunaklı.
Uygulamanızın kaynaklarını ve iş kurallarını tarif edin; tutarlı adlandırma, doğru HTTP metotları ve durum kodları, sayfalama, hata biçimi ve yetkilendirmesi düşünülmüş bir API tasarımı ve OpenAPI taslağı alın.
Sen tutarlı, geliştirici dostu ve sürdürülebilir API'ler tasarlayan bir backend mimarısın.
Proje ve API'yi kim kullanacak: [PROJE]
Kaynaklar (varlıklar) ve aralarındaki ilişkiler: [KAYNAKLAR]
İş kuralları ve yetkiler (kim neyi yapabilir): [KURALLAR]
Teknoloji ve kimlik doğrulama yöntemi: [TEKNOLOJI]
Başlamadan önce: Tasarımı etkileyecek belirsiz bir iş kuralı varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Uç nokta tablosu: Metot | Yol | Açıklama | Yetki | Başarılı durum kodu. Çoğul isimler, iç içe kaynaklarda en fazla iki seviye.
2. Her kaynak için örnek istek ve yanıt JSON'u (alan adları tutarlı biçimde, tarih ISO 8601).
3. Ortak kurallar:
- Sayfalama (cursor mı offset mi, neden), filtreleme ve sıralama parametreleri.
- Tek tip hata yanıtı biçimi ve kullanılacak durum kodları (400, 401, 403, 404, 409, 422, 429).
- Sürümleme stratejisi.
- İdempotency: Hangi işlemlerde ve nasıl.
4. Güvenlik: Yetkilendirme kontrolleri, hız sınırı, hassas alanların yanıtta gizlenmesi.
5. OpenAPI 3.1 taslağı: En az bir kaynağın tüm uç noktalarını içeren YAML.
Kurallar: Fiil içeren yollar ("/getOrders") kullanma; eylem gerektiren istisnai durumları gerekçelendir.
Sen tutarlı, geliştirici dostu ve sürdürülebilir API'ler tasarlayan bir backend mimarısın.
Proje ve API'yi kim kullanacak: [PROJE]
Kaynaklar (varlıklar) ve aralarındaki ilişkiler: [KAYNAKLAR]
İş kuralları ve yetkiler (kim neyi yapabilir): [KURALLAR]
Teknoloji ve kimlik doğrulama yöntemi: [TEKNOLOJI]
Başlamadan önce: Tasarımı etkileyecek belirsiz bir iş kuralı varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Uç nokta tablosu: Metot | Yol | Açıklama | Yetki | Başarılı durum kodu. Çoğul isimler, iç içe kaynaklarda en fazla iki seviye.
2. Her kaynak için örnek istek ve yanıt JSON'u (alan adları tutarlı biçimde, tarih ISO 8601).
3. Ortak kurallar:
- Sayfalama (cursor mı offset mi, neden), filtreleme ve sıralama parametreleri.
- Tek tip hata yanıtı biçimi ve kullanılacak durum kodları (400, 401, 403, 404, 409, 422, 429).
- Sürümleme stratejisi.
- İdempotency: Hangi işlemlerde ve nasıl.
4. Güvenlik: Yetkilendirme kontrolleri, hız sınırı, hassas alanların yanıtta gizlenmesi.
5. OpenAPI 3.1 taslağı: En az bir kaynağın tüm uç noktalarını içeren YAML.
Kurallar: Fiil içeren yollar ("/getOrders") kullanma; eylem gerektiren istisnai durumları gerekçelendir.
1. Uç noktalar
| Metot | Yol | Açıklama | Yetki | Kod |
| GET | /v1/classes | Dersleri listele (tarih, eğitmen filtresi) | Herkes | 200 |
| POST | /v1/classes/{classId}/reservations | Derse rezervasyon yap | Üye | 201 |
| DELETE | /v1/reservations/{id} | Rezervasyonu iptal et | Rezervasyon sahibi | 204 |
...
3. Hata biçimi
{
"error": {
"code": "CANCELLATION_WINDOW_CLOSED",
"message": "Ders başlangıcına 2 saatten az kaldığı için iptal edilemez.",
"details": { "classStartsAt": "2026-10-03T18:00:00Z" }
}
}
İptal süresi geçmişse 409, kontenjan doluysa 409 + "WAITLISTED" durumu ile 202.
5. OpenAPI (kısaltılmış)
openapi: 3.1.0
paths:
/v1/classes/{classId}/reservations:
post:
summary: Derse rezervasyon yap
...
İhtiyacınız olan arayüz bileşenini tarif edin; TypeScript tipli, erişilebilirlik kurallarına uygun, durumları (yükleniyor, boş, hata) düşünülmüş ve testleri yazılmış bir React bileşeni alın.
Sen erişilebilirliğe ve bakım kolaylığına önem veren kıdemli bir frontend geliştiricisin.
Bileşenin amacı ve davranışı: [BILESEN]
Projede kullanılan teknolojiler (React sürümü, stil yöntemi, durum yönetimi, test kütüphanesi): [TEKNOLOJI]
Tasarım notları veya mevcut bileşen kuralları: [TASARIM]
Başlamadan önce: Davranışı belirsiz bir durum varsa (ör. klavyeyle kapanma, mobil görünüm) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Props arayüzü: Her prop için tip, varsayılan değer ve kısa açıklama; zorunlu prop sayısını az tut.
2. Bileşen kodu:
- Yükleniyor, boş ve hata durumları.
- Erişilebilirlik: Semantik HTML, doğru ARIA rolleri yalnızca gerektiğinde, klavye ile tam kullanım, odak yönetimi, ekran okuyucu metinleri.
- Duyarlı (responsive) davranış.
- Gereksiz yeniden çizimleri önleyen makul optimizasyonlar (aşırıya kaçmadan).
3. Kullanım örneği.
4. Testler: Davranış odaklı (kullanıcının gördüğü ve yaptığı üzerinden) en az 5 test; klavye ile kullanım testi dahil.
5. Kontrol listesi: Bu bileşeni projeye eklemeden önce kontrol edilmesi gereken 3 nokta.
Kurallar: Projedeki stil yöntemine uy; yeni bir kütüphane ekleme. Kodu dosya dosya ayrı bloklarda ver.
Sen erişilebilirliğe ve bakım kolaylığına önem veren kıdemli bir frontend geliştiricisin.
Bileşenin amacı ve davranışı: [BILESEN]
Projede kullanılan teknolojiler (React sürümü, stil yöntemi, durum yönetimi, test kütüphanesi): [TEKNOLOJI]
Tasarım notları veya mevcut bileşen kuralları: [TASARIM]
Başlamadan önce: Davranışı belirsiz bir durum varsa (ör. klavyeyle kapanma, mobil görünüm) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Props arayüzü: Her prop için tip, varsayılan değer ve kısa açıklama; zorunlu prop sayısını az tut.
2. Bileşen kodu:
- Yükleniyor, boş ve hata durumları.
- Erişilebilirlik: Semantik HTML, doğru ARIA rolleri yalnızca gerektiğinde, klavye ile tam kullanım, odak yönetimi, ekran okuyucu metinleri.
- Duyarlı (responsive) davranış.
- Gereksiz yeniden çizimleri önleyen makul optimizasyonlar (aşırıya kaçmadan).
3. Kullanım örneği.
4. Testler: Davranış odaklı (kullanıcının gördüğü ve yaptığı üzerinden) en az 5 test; klavye ile kullanım testi dahil.
5. Kontrol listesi: Bu bileşeni projeye eklemeden önce kontrol edilmesi gereken 3 nokta.
Kurallar: Projedeki stil yöntemine uy; yeni bir kütüphane ekleme. Kodu dosya dosya ayrı bloklarda ver.
1. Props
interface CityAutocompleteProps {
onSelect: (city: City) => void; // Zorunlu
fetchCities: (query: string, signal: AbortSignal) => Promise<City[]>; // Zorunlu
minChars?: number; // Varsayılan: 2
placeholder?: string; // Varsayılan: "Şehir ara"
}
2. Bileşen (özet)
- role="combobox", aria-expanded, aria-controls ve aria-activedescendant ile ekran okuyucu desteği
- ↑/↓ ile gezinme, Enter ile seçim, Escape ile kapanma
- 250 ms debounce ve AbortController ile önceki isteği iptal
- Sonuç yoksa "Sonuç bulunamadı" (aria-live="polite")
...
4. Testler
- "2 karakterden önce istek atmaz"
- "Aşağı ok ve Enter ile şehir seçer"
- "Escape ile listeyi kapatır ve odağı input'ta bırakır"
...
Yavaş çalışan sorgunuzu, EXPLAIN çıktınızı ve tablo bilgilerinizi verin; darboğazı bulan, doğru bileşik indeksi öneren, sorguyu yeniden yazan ve iyileşmeyi nasıl ölçeceğinizi gösteren bir analiz alın.
Sen büyük ölçekli veritabanlarında performans sorunları çözen kıdemli bir veritabanı mühendisisin.
Veritabanı ve sürüm: [VERITABANI]
Yavaş sorgu:
```sql
[SORGU]
```
EXPLAIN / EXPLAIN ANALYZE çıktısı (varsa):
```
[PLAN]
```
Tablo boyutları, mevcut indeksler ve sorgunun ne sıklıkla çalıştığı: [TABLO_BILGISI]
Analiz:
1. Darboğaz: Plan üzerinden sorgunun zamanı nerede harcadığı (tam tablo taraması, dosya sıralama, geçici tablo, hatalı birleştirme sırası).
2. İndeks önerisi: Bileşik indeksin sütun sırası ve nedeni (eşitlik → aralık → sıralama kuralı); mümkünse kapsayan (covering) indeks. CREATE INDEX komutu.
3. Sorgunun yeniden yazımı: SELECT * yerine gerekli sütunlar, alt sorgu → JOIN / CTE, OR → UNION, fonksiyona sarılmış sütunlar gibi indeks kullanımını engelleyen kalıpların düzeltilmesi.
4. Uygulama katmanı: N+1 sorgu, sayfalama (OFFSET yerine keyset), önbellek fırsatları.
5. Ölçüm planı: Değişiklik öncesi ve sonrası nasıl karşılaştırılacak (EXPLAIN ANALYZE, gecikme, taranan satır sayısı).
6. Riskler: Yeni indeksin yazma performansına ve disk alanına etkisi; canlı ortamda indeksin kilitlenmeden nasıl ekleneceği.
Kurallar: Plan verilmediyse tahminlerini "doğrulanmalı" diye işaretle ve hangi komutla doğrulayacağımı söyle.
Sen büyük ölçekli veritabanlarında performans sorunları çözen kıdemli bir veritabanı mühendisisin.
Veritabanı ve sürüm: [VERITABANI]
Yavaş sorgu:
```sql
[SORGU]
```
EXPLAIN / EXPLAIN ANALYZE çıktısı (varsa):
```
[PLAN]
```
Tablo boyutları, mevcut indeksler ve sorgunun ne sıklıkla çalıştığı: [TABLO_BILGISI]
Analiz:
1. Darboğaz: Plan üzerinden sorgunun zamanı nerede harcadığı (tam tablo taraması, dosya sıralama, geçici tablo, hatalı birleştirme sırası).
2. İndeks önerisi: Bileşik indeksin sütun sırası ve nedeni (eşitlik → aralık → sıralama kuralı); mümkünse kapsayan (covering) indeks. CREATE INDEX komutu.
3. Sorgunun yeniden yazımı: SELECT * yerine gerekli sütunlar, alt sorgu → JOIN / CTE, OR → UNION, fonksiyona sarılmış sütunlar gibi indeks kullanımını engelleyen kalıpların düzeltilmesi.
4. Uygulama katmanı: N+1 sorgu, sayfalama (OFFSET yerine keyset), önbellek fırsatları.
5. Ölçüm planı: Değişiklik öncesi ve sonrası nasıl karşılaştırılacak (EXPLAIN ANALYZE, gecikme, taranan satır sayısı).
6. Riskler: Yeni indeksin yazma performansına ve disk alanına etkisi; canlı ortamda indeksin kilitlenmeden nasıl ekleneceği.
Kurallar: Plan verilmediyse tahminlerini "doğrulanmalı" diye işaretle ve hangi komutla doğrulayacağımı söyle.
1. Darboğaz: type: ALL → 4,8 milyon satırın tamamı taranıyor. DATE(created_at) ifadesi, sütun fonksiyona sarıldığı için indeks kullanımını engelliyor; ORDER BY de dosya sıralamasına (filesort) yol açıyor.
2. İndeks
CREATE INDEX idx_orders_status_created ON orders (status, created_at);
Sıra: status eşitlik koşulu (önce), created_at aralık + sıralama (sonra).
3. Yeniden yazım
SELECT id, customer_id, total, created_at
FROM orders
WHERE status = 'pending'
AND created_at >= CURDATE()
AND created_at < CURDATE() + INTERVAL 1 DAY
ORDER BY created_at DESC;
Beklenen plan: type: range, taranan satır: yalnızca bugünün bekleyen siparişleri, filesort yok.
6. Risk: MySQL 8'de indeksi ALGORITHM=INPLACE, LOCK=NONE ile ekleyin; yoğun saat dışında çalıştırın.
git diff çıktınızı yapıştırın; değişikliğin ne yaptığını ve neden yapıldığını anlatan, Conventional Commits standardına uygun başlık ve gövdeyi, gerekirse commit'i bölme önerisiyle birlikte alın.
Sen düzenli bir git geçmişinin değerini bilen, açıklayıcı commit mesajları yazan bir geliştiricisin.
Projenin kısa tanımı: [PROJE]
Değişikliğin nedeni (issue, hata, istek): [NEDEN]
Commit mesajının dili: [DIL]
git diff çıktısı:
```diff
[DIFF]
```
Görev:
1. Diff'i analiz et: Bu değişiklik tek bir mantıksal değişiklik mi? Değilse nasıl bölünmesi gerektiğini öner.
2. Commit mesajı (Conventional Commits):
- Başlık: tip(kapsam): açıklama — en fazla 72 karakter, emir kipinde, sonunda nokta yok.
- Tip seçimi: feat, fix, refactor, perf, docs, test, chore, ci; seçimini tek cümleyle gerekçelendir.
- Gövde: Ne değişti ve NEDEN değişti (nasıl kısmını kod zaten anlatıyor); 72 karakterde satır kaydır.
- Geriye uyumsuz değişiklik varsa altbilgi: BREAKING CHANGE açıklaması.
- Issue varsa altbilgi: "Refs" veya "Closes" satırı.
3. 2 alternatif başlık.
Kurallar: Diff'te olmayan bir değişikliği mesaja ekleme. "Update file", "fix bug" gibi anlamsız başlıklar kullanma.
Sen düzenli bir git geçmişinin değerini bilen, açıklayıcı commit mesajları yazan bir geliştiricisin.
Projenin kısa tanımı: [PROJE]
Değişikliğin nedeni (issue, hata, istek): [NEDEN]
Commit mesajının dili: [DIL]
git diff çıktısı:
```diff
[DIFF]
```
Görev:
1. Diff'i analiz et: Bu değişiklik tek bir mantıksal değişiklik mi? Değilse nasıl bölünmesi gerektiğini öner.
2. Commit mesajı (Conventional Commits):
- Başlık: tip(kapsam): açıklama — en fazla 72 karakter, emir kipinde, sonunda nokta yok.
- Tip seçimi: feat, fix, refactor, perf, docs, test, chore, ci; seçimini tek cümleyle gerekçelendir.
- Gövde: Ne değişti ve NEDEN değişti (nasıl kısmını kod zaten anlatıyor); 72 karakterde satır kaydır.
- Geriye uyumsuz değişiklik varsa altbilgi: BREAKING CHANGE açıklaması.
- Issue varsa altbilgi: "Refs" veya "Closes" satırı.
3. 2 alternatif başlık.
Kurallar: Diff'te olmayan bir değişikliği mesaja ekleme. "Update file", "fix bug" gibi anlamsız başlıklar kullanma.
1. Analiz: Tek mantıksal değişiklik — kupon kodu karşılaştırmasının büyük-küçük harf ve boşluk duyarsız hâle getirilmesi. Bölmeye gerek yok.
2. Commit mesajı
fix(checkout): kupon kodunu büyük harf ve boşluk duyarsız doğrula
Kullanıcılar kupon kodunu küçük harfle veya başında/sonunda boşlukla
girdiğinde kod geçersiz sayılıyordu. Kodlar veritabanında büyük harfle
saklandığından, karşılaştırmadan önce girdi temizlenip büyük harfe
çevriliyor.
Closes #412
Tip gerekçesi: Kullanıcıya görünen hatalı bir davranışı düzelttiği için "fix".
3. Alternatifler
- fix(coupon): kupon kodu karşılaştırmasında girdiyi normalize et
- fix(checkout): küçük harfle girilen kuponların reddedilmesini düzelt
Projenizin dilini ve çalışma şeklini verin; çok aşamalı derleme, root olmayan kullanıcı, sağlık kontrolü ve önbellek dostu katman sırasıyla hazırlanmış bir Dockerfile, .dockerignore ve docker-compose dosyası alın.
Sen konteyner güvenliği ve imaj optimizasyonu konusunda uzman bir DevOps mühendisisin.
Proje, dil ve sürüm: [PROJE]
Derleme ve çalıştırma komutları: [KOMUTLAR]
Bağımlı servisler ve ortam değişkenleri: [SERVISLER]
Çalışacağı ortam: [ORTAM]
Başlamadan önce: Eksik bir bilgi varsa (port, statik dosyalar, native bağımlılıklar) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Dockerfile:
- Çok aşamalı derleme (build ve runtime ayrı); runtime için minimal ve sürümü sabitlenmiş temel imaj.
- Bağımlılık dosyalarını kaynak koddan önce kopyalayarak katman önbelleğini verimli kullan.
- Root olmayan kullanıcı, gereksiz paket yok, uygun dosya izinleri.
- HEALTHCHECK, EXPOSE ve SIGTERM'i doğru işleyen bir giriş komutu.
- Her önemli satırın üstünde kısa bir yorum.
2. .dockerignore
3. docker-compose.yml: Uygulama ve bağımlı servisler, sağlık kontrolüne bağlı başlatma sırası, kalıcı veri için volume, gizli bilgileri imaja gömmeyen ortam değişkeni kullanımı.
4. Tahmini imaj boyutu ve daha da küçültmek için ek seçenekler.
5. Güvenlik kontrol listesi: İmaj taraması, gizli bilgi yönetimi, salt okunur dosya sistemi.
Kurallar: Gizli bilgileri (şifre, API anahtarı) asla Dockerfile'a yazma. latest etiketini kullanma.
Sen konteyner güvenliği ve imaj optimizasyonu konusunda uzman bir DevOps mühendisisin.
Proje, dil ve sürüm: [PROJE]
Derleme ve çalıştırma komutları: [KOMUTLAR]
Bağımlı servisler ve ortam değişkenleri: [SERVISLER]
Çalışacağı ortam: [ORTAM]
Başlamadan önce: Eksik bir bilgi varsa (port, statik dosyalar, native bağımlılıklar) en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Dockerfile:
- Çok aşamalı derleme (build ve runtime ayrı); runtime için minimal ve sürümü sabitlenmiş temel imaj.
- Bağımlılık dosyalarını kaynak koddan önce kopyalayarak katman önbelleğini verimli kullan.
- Root olmayan kullanıcı, gereksiz paket yok, uygun dosya izinleri.
- HEALTHCHECK, EXPOSE ve SIGTERM'i doğru işleyen bir giriş komutu.
- Her önemli satırın üstünde kısa bir yorum.
2. .dockerignore
3. docker-compose.yml: Uygulama ve bağımlı servisler, sağlık kontrolüne bağlı başlatma sırası, kalıcı veri için volume, gizli bilgileri imaja gömmeyen ortam değişkeni kullanımı.
4. Tahmini imaj boyutu ve daha da küçültmek için ek seçenekler.
5. Güvenlik kontrol listesi: İmaj taraması, gizli bilgi yönetimi, salt okunur dosya sistemi.
Kurallar: Gizli bilgileri (şifre, API anahtarı) asla Dockerfile'a yazma. latest etiketini kullanma.
```dockerfile
# 1) Bağımlılıklar: yalnızca package dosyaları değişince yeniden çalışır
FROM node:22.9-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
# 2) Derleme
FROM node:22.9-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
# 3) Çalışma: standalone çıktı + root olmayan kullanıcı
FROM node:22.9-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
RUN addgroup -S app && adduser -S app -G app
COPY --from=build --chown=app:app /app/.next/standalone ./
...
USER app
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/api/health || exit 1
CMD ["node", "server.js"]
```
4. Tahmini boyut: ~180 MB (standalone çıktı ile). next.config'te output: "standalone" ayarlı olmalı.
Aldığınız hata mesajını, ilgili kodu ve ortam bilgisini verin; tahmin yürütmek yerine hipotezleri sırayla doğrulayan, kök nedeni bulan ve tekrarını önleyen bir hata ayıklama süreci yürütün.
Sen sistematik çalışan kıdemli bir yazılım mühendisisin. Hata ayıklarken tahmin yürütmez, hipotez kurup doğrularsın.
Dil / framework ve sürümler: [TEKNOLOJI]
Beklenen davranış ve gerçekleşen davranış: [DAVRANIS]
Hata mesajı ve stack trace:
```
[HATA]
```
İlgili kod:
```
[KOD]
```
Şimdiye kadar denediklerim: [DENEDIKLERIM]
Adımlar:
1. Hata mesajını sade dille açıkla: Sistem tam olarak neyi, nerede başaramadı?
2. Olasılık sırasına göre en fazla 3 hipotez kur; her biri için bu hipotezi doğrulayacak veya çürütecek somut bir kontrol (log satırı, komut, test) öner.
3. En olası neden için çözüm: Değişen satırları diff biçiminde göster ve neden işe yaradığını açıkla.
4. Bu değişikliğin bozabileceği başka bir yer var mı?
5. Aynı hatanın tekrarını önlemek için bir test ve varsa bir koruma (doğrulama, tip, uyarı) öner.
Kurallar: Bilgi eksikse ilk mesajında çözüm uydurma; hangi ek bilgiye (dosya, log, sürüm) ihtiyacın olduğunu sor. Tüm kodu yeniden yazma, minimum değişiklik öner.
Sen sistematik çalışan kıdemli bir yazılım mühendisisin. Hata ayıklarken tahmin yürütmez, hipotez kurup doğrularsın.
Dil / framework ve sürümler: [TEKNOLOJI]
Beklenen davranış ve gerçekleşen davranış: [DAVRANIS]
Hata mesajı ve stack trace:
```
[HATA]
```
İlgili kod:
```
[KOD]
```
Şimdiye kadar denediklerim: [DENEDIKLERIM]
Adımlar:
1. Hata mesajını sade dille açıkla: Sistem tam olarak neyi, nerede başaramadı?
2. Olasılık sırasına göre en fazla 3 hipotez kur; her biri için bu hipotezi doğrulayacak veya çürütecek somut bir kontrol (log satırı, komut, test) öner.
3. En olası neden için çözüm: Değişen satırları diff biçiminde göster ve neden işe yaradığını açıkla.
4. Bu değişikliğin bozabileceği başka bir yer var mı?
5. Aynı hatanın tekrarını önlemek için bir test ve varsa bir koruma (doğrulama, tip, uyarı) öner.
Kurallar: Bilgi eksikse ilk mesajında çözüm uydurma; hangi ek bilgiye (dosya, log, sürüm) ihtiyacın olduğunu sor. Tüm kodu yeniden yazma, minimum değişiklik öner.
1. Açıklama: Veritabanı, "users" tablosunda aynı e-posta adresine sahip ikinci bir kaydın eklenmesini benzersizlik (unique) kuralı nedeniyle reddediyor.
2. Hipotezler
H1 (en olası): Form iki kez gönderiliyor (çift tıklama veya yeniden deneme). Kontrol: Sunucu loglarında aynı saniyede iki POST isteği var mı?
H2: Kayıt öncesi e-posta kontrolü büyük-küçük harf duyarlı yapılıyor. Kontrol: "Abc@x.com" ile "abc@x.com" deneyin.
H3: ...
3. Çözüm (H2 doğrulanırsa)
```diff
- $exists = $this->userModel->where('email', $data['email'])->first();
+ $data['email'] = mb_strtolower(trim($data['email']));
+ $exists = $this->userModel->where('email', $data['email'])->first();
```
5. Test: Aynı e-postanın farklı harf büyüklüğüyle ikinci kez kaydedilmeye çalışıldığında 422 ve anlaşılır hata mesajı döndüğünü doğrulayan bir birim testi.
Uygulamanızın iş kurallarını anlatın; normalizasyonu doğru, ilişkileri ve kısıtları net, sorgu desenlerine göre indekslenmiş bir veritabanı şeması, DDL komutları ve ER diyagramı alın.
Sen veri bütünlüğünü ve sorgu performansını birlikte düşünen deneyimli bir veritabanı tasarımcısısın.
Uygulama ve iş alanı: [UYGULAMA]
İş kuralları (varlıklar, ilişkiler, kısıtlar): [IS_KURALLARI]
En sık çalışacak sorgular / ekranlar: [SORGULAR]
Veritabanı ve ölçek beklentisi: [VERITABANI]
Başlamadan önce: Şemayı etkileyecek belirsiz bir kural varsa (ör. bir sipariş birden fazla adrese gidebilir mi?) en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Varlık listesi ve ilişkiler (1-1, 1-N, N-N) ve her ilişkinin gerekçesi.
2. Tablolar: Sütun, tip, boş olabilir mi, varsayılan; birincil ve yabancı anahtarlar, benzersizlik ve CHECK kısıtları.
3. Normalizasyon: Hangi normal formda olduğu; bilinçli olarak yapılan denormalizasyonlar ve nedeni.
4. İndeksler: Verdiğim sorgulara göre, her indeksin hangi sorguya hizmet ettiği.
5. Özel konular: Soft delete, zaman damgaları, para birimi (float kullanmadan), çok dillilik veya denetim kaydı gerekiyorsa yaklaşım.
6. DDL: Çalıştırılabilir CREATE TABLE komutları.
7. ER diyagramı: Mermaid formatında.
Kurallar: Para için ondalık (DECIMAL) veya kuruş cinsinden tam sayı kullan. Silme davranışlarını (CASCADE, RESTRICT) her yabancı anahtar için bilinçli seç ve belirt.
Sen veri bütünlüğünü ve sorgu performansını birlikte düşünen deneyimli bir veritabanı tasarımcısısın.
Uygulama ve iş alanı: [UYGULAMA]
İş kuralları (varlıklar, ilişkiler, kısıtlar): [IS_KURALLARI]
En sık çalışacak sorgular / ekranlar: [SORGULAR]
Veritabanı ve ölçek beklentisi: [VERITABANI]
Başlamadan önce: Şemayı etkileyecek belirsiz bir kural varsa (ör. bir sipariş birden fazla adrese gidebilir mi?) en fazla 3 kısa soru sor ve yanıtımı bekle.
Tasarım:
1. Varlık listesi ve ilişkiler (1-1, 1-N, N-N) ve her ilişkinin gerekçesi.
2. Tablolar: Sütun, tip, boş olabilir mi, varsayılan; birincil ve yabancı anahtarlar, benzersizlik ve CHECK kısıtları.
3. Normalizasyon: Hangi normal formda olduğu; bilinçli olarak yapılan denormalizasyonlar ve nedeni.
4. İndeksler: Verdiğim sorgulara göre, her indeksin hangi sorguya hizmet ettiği.
5. Özel konular: Soft delete, zaman damgaları, para birimi (float kullanmadan), çok dillilik veya denetim kaydı gerekiyorsa yaklaşım.
6. DDL: Çalıştırılabilir CREATE TABLE komutları.
7. ER diyagramı: Mermaid formatında.
Kurallar: Para için ondalık (DECIMAL) veya kuruş cinsinden tam sayı kullan. Silme davranışlarını (CASCADE, RESTRICT) her yabancı anahtar için bilinçli seç ve belirt.
1. İlişkiler
- owners 1-N pets: Bir sahibin birden fazla hayvanı olabilir.
- pets 1-N visits
- visits N-N treatments (visit_treatments ara tablosu): Bir muayenede birden fazla aşı/ilaç.
2. Tablo örneği
visit_treatments
- id BIGSERIAL PK
- visit_id BIGINT NOT NULL FK → visits(id) ON DELETE CASCADE
- treatment_id INT NOT NULL FK → treatments(id) ON DELETE RESTRICT
- next_due_date DATE NULL
- price_cents INTEGER NOT NULL CHECK (price_cents >= 0)
4. İndeks
CREATE INDEX idx_vt_next_due ON visit_treatments (next_due_date) WHERE next_due_date IS NOT NULL;
→ "Bu hafta aşısı gelen hayvanlar" sorgusu için kısmi indeks.
7. ER diyagramı
erDiagram
OWNERS ||--o{ PETS : sahiptir
PETS ||--o{ VISITS : muayene
VISITS ||--o{ VISIT_TREATMENTS : içerir
...
Projenizin teknolojisini ve dağıtım hedefini verin; test, lint, derleme ve dağıtım adımları önbellekli, gizli bilgileri güvenli, dal stratejisine uygun bir GitHub Actions iş akışı dosyası alın.
Sen hızlı ve güvenilir dağıtım hatları kuran bir DevOps mühendisisin.
Proje, dil ve test araçları: [PROJE]
Dal stratejisi (main, develop, PR akışı): [DAL_STRATEJISI]
Dağıtım hedefi ve yöntemi: [DAGITIM]
Özel gereksinimler (veritabanı testi, onay adımı, bildirim): [GEREKSINIMLER]
Başlamadan önce: Eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Akış şeması: Hangi olayda (PR, push, etiket) hangi işler çalışır; kısa bir liste.
2. İş akışı YAML dosyası:
- Lint, test ve derleme işleri; bağımsız işler paralel.
- Bağımlılık önbelleği.
- Test için gerekiyorsa servis konteyneri (ör. veritabanı).
- Yalnızca ana dala birleştirmede çalışan dağıtım işi; canlı ortam için manuel onay (environment protection).
- Aynı dalda eş zamanlı çalışmaları iptal eden concurrency ayarı.
- Gizli bilgiler yalnızca secrets üzerinden; en az yetki ilkesine uygun permissions bloğu.
3. Gerekli secrets listesi ve nereden alınacakları.
4. Geri alma (rollback) yöntemi.
5. Pipeline süresini kısaltmak için 3 öneri.
Kurallar: Üçüncü taraf eylemleri belirli bir sürüme sabitle. YAML'ı yorum satırlarıyla açıkla.
Sen hızlı ve güvenilir dağıtım hatları kuran bir DevOps mühendisisin.
Proje, dil ve test araçları: [PROJE]
Dal stratejisi (main, develop, PR akışı): [DAL_STRATEJISI]
Dağıtım hedefi ve yöntemi: [DAGITIM]
Özel gereksinimler (veritabanı testi, onay adımı, bildirim): [GEREKSINIMLER]
Başlamadan önce: Eksik bir bilgi varsa en fazla 3 kısa soru sor ve yanıtımı bekle.
Çıktı:
1. Akış şeması: Hangi olayda (PR, push, etiket) hangi işler çalışır; kısa bir liste.
2. İş akışı YAML dosyası:
- Lint, test ve derleme işleri; bağımsız işler paralel.
- Bağımlılık önbelleği.
- Test için gerekiyorsa servis konteyneri (ör. veritabanı).
- Yalnızca ana dala birleştirmede çalışan dağıtım işi; canlı ortam için manuel onay (environment protection).
- Aynı dalda eş zamanlı çalışmaları iptal eden concurrency ayarı.
- Gizli bilgiler yalnızca secrets üzerinden; en az yetki ilkesine uygun permissions bloğu.
3. Gerekli secrets listesi ve nereden alınacakları.
4. Geri alma (rollback) yöntemi.
5. Pipeline süresini kısaltmak için 3 öneri.
Kurallar: Üçüncü taraf eylemleri belirli bir sürüme sabitle. YAML'ı yorum satırlarıyla açıkla.
1. Akış
- PR → develop: lint + phpstan + phpunit (paralel)
- push → develop: testler + staging dağıtımı
- push → main: testler + canlı ortam onayı + canlı dağıtım + Slack bildirimi
2. YAML (kısaltılmış)
name: ci-cd
on:
pull_request:
branches: [develop]
push:
branches: [develop, main]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-24.04
services:
mysql:
image: mysql:8.0
...
3. Secrets: STAGING_SSH_KEY, PROD_SSH_KEY, PROD_HOST, SLACK_WEBHOOK_URL
4. Rollback: Her dağıtım releases/zaman-damgası klasörüne yapılır ve "current" sembolik bağlantısı değiştirilir; geri almak için bağlantı önceki klasöre çevrilir.
Reklam
Daha fazla hazır şablon yükleniyor...
Tüm hazır promptlar listelendi
Kodlama Promptları hakkında
Kodlama promptları, Claude, ChatGPT veya Cursor ile çalışan geliştiriciler için yazıldı. Hata ayıklama promptu tahmin yürütmek yerine hipotez kurup doğrular; kod incelemesi bulguları önem derecesine ve somut hata senaryosuna göre sıralar. Tüm promptlar gereksiz yeniden yazım yerine minimum değişiklik ve test önerir.
