--- title: "Yerel Geliştirme Ortamını Tek Komutla Kurmak" url: "https://cilginyazilim.com/blog/yerel-gelistirme-ortamini-tek-komutla-kurmak" description: "Yeni geliştiricinin ilk günü neden iki gün sürer? Docker Compose ile tekrarlanabilir yerel ortam, veri tohumlama, hızlı kurulum ve sık yapılan hatalar." published: "2026-08-12T18:00:00+03:00" modified: "2026-08-12T18:01:13+03:00" author: "superadmin" category: "Geliştirici Araçları" tags: ["otomasyon", "devops", "Yazılım Araçları", "makefile", "geliştirici deneyimi", "onboarding", "tekrarlanabilirlik", "geliştirme ortamı", "docker compose", "yerel kurulum", "konteyner", "veri tohumlama", "ekip verimliliği"] site: "CılgınYazılım" language: "tr" --- # Yerel Geliştirme Ortamını Tek Komutla Kurmak "Bende çalışıyor" cümlesinin kaynağı genellikle ortam farkıdır. Kurulumu koda dökmek bu farkı bitirir. Yeni bir geliştiricinin ilk günü çoğu ekipte aynı geçer: depo klonlanır, benioku dosyası açılır ve ardından sekiz saatlik bir kurulum macerası başlar. Yanlış PHP sürümü, eksik bir eklenti, çalışmayan bir veritabanı bağlantısı… Oysa iyi kurulmuş bir **geliştirme ortamı** tek komutla ayağa kalkar ve bu, yalnızca ilk günü değil ekibin tüm yılını etkiler. ![Yerel geliştirme ortamı özellikleri](https://cilginyazilim.com/uploads/blog/2026/08/yerel-gelistirme-ortamini-tek-komutla-kurmak-ozet.png) *Boş bir veritabanıyla açılan uygulama, kurulmuş sayılmaz.* ## Neden önemli? Üç somut sebep **İşe alıştırma süresi.** Kurulum iki gün sürüyorsa, her yeni katılımda bu maliyet tekrar ödenir. Tek komuta indiğinde yeni geliştirici ilk gün gerçek bir katkı yapabilir — [ilk 30 gün planı](https://cilginyazilim.com/blog/yeni-gelistiricinin-ilk-30-gunu-ise-alistirma-plani) yazımızda anlattığımız sürecin ön koşuludur. **"Bende çalışıyor" tartışmasının sonu.** Ortam farkları, hata ayıklamada en çok zaman kaybettiren belirsizliktir. Sürümler tanımlıysa bu sınıf tamamen ortadan kalkar. **Cesaret.** Ortamı bozmaktan korkan geliştirici deneme yapmaz. Beş dakikada sıfırdan kurulabilen bir ortam, "sil baştan kur" seçeneğini gerçek kılar ve bu, öğrenmeyi hızlandırır. ## Konteyner: sürümleri tanıma dönüştürmek Bir compose dosyası, uygulamanın ihtiyaç duyduğu her şeyi (dil sürümü, veritabanı, önbellek, arama servisi) tek bir tanımda toplar. Bu tanım depoda durduğu için sürüm kontrolünden geçer ve değiştiğinde herkes aynı anda güncellenir. Buradaki asıl kazanç izolasyon değil *tekrarlanabilirliktir*: aynı tanımdan doğan ortam, her makinede aynıdır. Aynı ilkenin sunucu tarafındaki karşılığı için [altyapıyı kod olarak yönetmek](https://cilginyazilim.com/blog/altyapiyi-kod-olarak-yonetmek-iac) yazımıza bakabilirsiniz. ## Tek giriş noktası kurun Yeni gelen kişinin altı farklı komutu ezberlemesi gerekmemeli. Basit bir `make` dosyası veya tek bir kurulum betiği, tüm adımları bir isim altında toplar: ``` make kur # bağımlılıklar + konteynerler + göçler + örnek veri make baslat # ortamı ayağa kaldır make test # test takımını çalıştır make sifirla # her şeyi sil, sıfırdan kur ``` Bu dört hedef, çoğu projede yeterlidir. Değeri, komutları basitleştirmesinden çok, ekibin ortak bir dili olmasıdır. ## En çok atlanan adım: örnek veri Uygulama ayağa kalkar ama veritabanı boştur; geliştirici hiçbir ekranı gerçekten göremez. Bu, kurulumun yarım kaldığı en yaygın noktadır. Çözüm, gerçekçi bir tohumlama (seed) betiğidir: birkaç kullanıcı, farklı rollerde hesaplar, örnek siparişler, hata senaryolarını tetikleyen kayıtlar. Üretim verisinin kopyalanması ise ciddi bir gizlilik riskidir; gerçekten gerekiyorsa kişisel veriler mutlaka maskelenmelidir — [veri gizliliği](https://cilginyazilim.com/blog/yapay-zeka-projelerinde-veri-gizliligi-kvkk) yazımızdaki ilkeler burada da geçerlidir. ## Sık yapılan hatalar **Sürümleri sabitlememek.** Tanımda `latest` kullanmak, bugün çalışan ortamın üç ay sonra farklı davranması demektir. Sürümler açıkça yazılmalıdır. **Yerel ile üretimin çok ayrışması.** Yerelde farklı bir veritabanı motoru kullanmak, kurulum kolaylığı sağlar ama en tehlikeli hataları üretime saklar. **Gerçek sırları yerele koymak.** Yerel ortam örnek değerlerle çalışmalıdır; üretim anahtarlarının geliştirici makinelerine dağılması sızıntının en yaygın yollarındandır — bkz. [sır yönetimi](https://cilginyazilim.com/blog/sirlarin-yonetimi-env-dosyasindan-sir-kasasina). **Belgeyi güncellememek.** Kurulum adımları değişip belge eskidiğinde, yeni gelen kişi çalışmayan talimatlarla saatler kaybeder. Bu yüzden en iyi belge, çalıştırılabilir bir betiktir: eskidiğinde sessizce yanıltmaz, hata verir. ## Performans: Windows ve macOS notu Konteyner tabanlı ortamlarda dosya paylaşımı, Linux dışı sistemlerde belirgin yavaşlık üretebilir. Pratik önlemler bellidir: bağımlılık klasörlerini paylaşılan birime koymamak, izlenen dosya sayısını azaltmak ve mümkünse yeni nesil dosya paylaşım seçeneklerini etkinleştirmek. Bu ayarlar yapılmadığında ekip, konteyner kullanımını "yavaş" diye terk etme eğilimine girer. ## Ne zaman gereksiz? Tek geliştiricili, tek servisli ve nadiren dokunulan bir projede tam kapsamlı bir kurulum fazla gelebilir. Bu durumda bile minimum standart geçerlidir: kurulum adımları depoda çalıştırılabilir tek bir betik olarak dursun. Otomasyon yatırımının ne zaman geri döndüğünü hesaplamak için [ne zaman script yazmalı](https://cilginyazilim.com/blog/tekrarlayan-isleri-otomatiklestirmek-ne-zaman-script-yazmali) yazımıza bakabilirsiniz. Konteyner yapılandırması için [Docker dokümantasyonu](https://docs.docker.com/) temel referanstır. ## Sonuç Tek komutla kurulabilen bir geliştirme ortamı, ekibin en sık ödediği görünmez faturayı ortadan kaldırır: kurulum saatleri, ortam farkından doğan hatalar ve deneme yapmaktan çekinme. Sürümleri tanımda sabitlemek, tüm adımları tek bir giriş noktasında toplamak, gerçekçi örnek veriyle gelmek ve kurulum belgesini betiğe çevirmek — bu dördü çoğu projede birkaç günlük iştir. Bugün şu testi yapın: en son katılan ekip arkadaşınıza sorun, kurulum kaç saat sürdü? Cevap bir saatin üzerindeyse, bu hafta yapılacak en değerli iş bellidir. ## Sıkça Sorulan Sorular ### Docker kullanmak zorunda mıyım? Hayır. Amaç konteyner değil tekrarlanabilirliktir; sürüm yöneticileri ve iyi yazılmış bir kurulum betiğiyle de sağlanabilir. Ancak birden çok servis (veritabanı, önbellek, kuyruk) devreye girdiğinde konteyner belirgin biçimde kolaylaştırır. ### Yerel ortam üretimle birebir aynı olmalı mı? Birebir aynı olması genellikle gereksiz ve pahalıdır, ancak kritik bileşenlerin (veritabanı motoru ve sürümü, dil sürümü) aynı olması şarttır. Bu bileşenlerdeki farklar en pahalı hataları üretime saklar. ### Örnek veri üretimini nasıl güncel tutarım? Tohumlama betiğini uygulama koduyla aynı depoda tutmak ve şema değiştiğinde birlikte güncellemek yeterlidir. Betik dağıtım hattında düzenli çalıştırılıyorsa bozulduğu anda fark edilir. ### Üretim veritabanının kopyasını yerelde kullanabilir miyim? Kişisel veri içeriyorsa doğrudan kullanılmamalıdır. Gerçekten gerekiyorsa maskelenmiş bir kopya üretilmeli ve bu işlem otomatik, tekrarlanabilir bir adım hâline getirilmelidir. --- Kaynak: [Yerel Geliştirme Ortamını Tek Komutla Kurmak](https://cilginyazilim.com/blog/yerel-gelistirme-ortamini-tek-komutla-kurmak)