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.

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ı 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 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 kurBu 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 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.
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ı yazımıza bakabilirsiniz. Konteyner yapılandırması için Docker dokümantasyonu 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 Sorulan Sorular
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.
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.
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.
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.
Yorumlar (0)
Bu yazıya henüz yorum yapılmamış. İlk yorumu siz yazın!
Yorum Yaz
Yorumunuz onaylandıktan sonra yayınlanır. Ekibimiz gerekirse konuyla ilgili bir yanıt da paylaşır.