Standart bir LAMP yapılandırmasında sosyal bir web sitesi çalıştırıyorduk. Canlı sunucu, Test sunucusu ve Geliştirme sunucumuzun yanı sıra yerel geliştirici makinelerimiz vardı. Hepsi GIT kullanılarak yönetildi.
Her makinede PHP dosyaları, ayrıca MySQL hizmeti ve kullanıcıların yükleyeceği Görseller içeren bir klasör vardı. Canlı sunucu 100K (!) Tekrarlayan kullanıcılara sahip oldu, dökümü yaklaşık 2GB (!), Görüntü klasörü yaklaşık 50GB (!) İdi. Gittiğimde, sunucumuz CPU, Ram ve en önemlisi eşzamanlı net bağlantı limitlerine ulaşıyordu (Hatta sunucunun 'lol' değerini maksimize etmek için kendi ağ kartı sürücümüzün sürümünü derledik). GIT'ye 2GB veri ve 50GB resim koyamadık ( ne de web sitenizle varsaymanız gerekmiyor ).
Tüm bunları GIT altında kolayca yönetmek için, bu klasör yollarını .gitignore'a ekleyerek ikili klasörleri (Görüntüleri içeren klasörler) yok sayarız. Ayrıca Apache belge kök yolunun dışında SQL adlı bir klasör vardı. Bu SQL klasöründe, SQL dosyalarımızı geliştiricilerden artımlı numaralara koyarız (001.florianm.sql, 001.johns.sql, 002.florianm.sql, vb.). Bu SQL dosyaları GIT tarafından da yönetildi. İlk sql dosyası gerçekten de büyük bir DB şeması kümesi içerir. GIT'e kullanıcı verileri eklemiyoruz (örn. Kullanıcı tablosunun veya yorum tablosunun kayıtları), ancak config veya topoloji veya siteye özgü diğer veriler gibi veriler sql dosyalarında (ve dolayısıyla GIT tarafından) tutulur. Çoğunlukla SQL şeması ve verileri ile ilgili olarak GIT tarafından neyin korunmadığını ve neyin korunmadığını belirleyen geliştiriciler (kodu en iyi bilen).
Bir sürüm yayınlandığında, yönetici dev sunucusunda oturum açar, canlı dalı tüm geliştiricilerle ve geliştirici makinesindeki gerekli dalları bir güncelleştirme dalına birleştirir ve test sunucusuna iletir. Test sunucusunda, Canlı sunucunun güncelleme işleminin hala geçerli olup olmadığını kontrol eder ve hızlı bir şekilde Apache'deki tüm trafiği bir yer tutucu siteye yönlendirir, bir DB dökümü oluşturur, çalışma dizinini 'canlı' dan 'güncellemeye yönlendirir ', tüm yeni sql dosyalarını mysql içine yürütür ve trafiği doğru siteye yeniden yönlendirir. Tüm paydaşlar test sunucusunu inceledikten sonra kabul ettiğinde, Yönetici aynı şeyi Test sunucusundan Canlı sunucuya da yaptı. Daha sonra, üretim sunucusundaki canlı dalı, tüm sunuculardaki ana şubeyle birleştirir ve tüm canlı şubeleri yeniden temel alır.
Test sunucusunda sorunlar varsa, örn. birleştirmelerin çok fazla çakışması vardı, daha sonra kod geri döndürüldü (çalışma dalını 'canlı' olarak işaret ediyor) ve sql dosyaları hiçbir zaman yürütülmedi. Sql dosyalarının yürütüldüğü anda, o zaman geri döndürülemez bir eylem olarak kabul edildi. SQL dosyaları düzgün çalışmıyorsa, DB Döküm kullanılarak geri yüklendi (ve geliştiriciler kötü test edilmiş SQL dosyaları sağlamak için söylendi).
Bugün, geliştiricilerin hem yükseltme sql dosyalarının eşit şekilde düşürülebileceğini test etmesi gereken eşdeğer dosya adlarına sahip bir sql-up ve sql-down klasörünü koruyoruz. Bu sonuçta bir bash betiği ile yürütülebilir, ancak insan gözlerinin yükseltme işlemini izlemeye devam etmesi iyi bir fikirdir.
Harika değil, yönetilebilir. Umarım bu gerçek hayattaki, pratik, nispeten yüksek kullanılabilirliğe sahip bir site hakkında fikir verir. Biraz modası geçmiş olsun, ama yine de takip etti.