Örneğin her gün 40bin teknik adamın her biri, kendi kodlarını yazıyor, sisteme yüklüyor.
Her gün başka 40bin teknik adam da kodları test eden kodlar yazıyor ve sisteme yüklüyor.
Sistem her gün yüklenen tüm bu kodları çalıştırıyor. Testleri geçen kodları kullanıma alıyorlar.
Toplam 80bin kişi filan yani. Öyle müdürüm amirim filan işe yaramaz. Boyutlar bizlerinki gibi değil.
80bin kişi derken, rakamlar üfürme değil, gerçek hayattan alınma.
Google gibi devasa bir teknoloji şirketi, 2 milyar satırlık koda ulaşan projelerini yönetmek için çok karmaşık ve iyi düşünülmüş bir yazılım geliştirme süreci kullanır. Her geliştiricinin bu devasa kod tabanına tam erişimi olması hem güvenlik hem de verimlilik açısından pek mümkün değil. Bu süreç birkaç aşamada yürütülür ve genellikle şu şekilde işler:
1. Kod Yönetim Sistemi (Version Control System)
Google, büyük projeleri yönetmek için devasa bir versiyon kontrol sistemi kullanır. Google'ın kendi içindeki sistemi Piper olarak adlandırılır ve bu, tüm kodların merkezi bir depoda tutulmasını sağlar. Geliştiriciler, bu sistemde sadece yetkili oldukları bölümleri görüp değiştirebilirler.
Kimler Kodlara Erişebiliyor?
Her geliştirici tüm koda erişemez. Şirketin yazılım geliştirme süreçleri, yetkilendirme ve rol tabanlı erişim kontrolü ile çalışır. Her geliştirici, üzerinde çalıştığı proje veya bileşenlerle ilgili sınırlı bir kod tabanına erişim sağlar. Örneğin, bir geliştirici arama motorunun sadece bir bölümünde çalışıyorsa, yalnızca o bölümle ilgili kodlara erişebilir.
2. Çalışma Şekli: "Branching" ve "Pull Request" (Kod İncelemeleri)
Google'da ya da diğer büyük teknoloji şirketlerinde, geliştiriciler genellikle bir projeyi doğrudan ana kod tabanı üzerinde değil, "branch" adı verilen dallar üzerinde geliştirirler. Geliştirici bir dal oluşturur, üzerinde çalışır ve işi bittiğinde bu dalı ana kod tabanına eklemek için bir talepte bulunur.
Süreç Şu Şekilde İşler:
Geliştirici kodu tamamlar: Geliştirici, görevini yerine getirmek için gerekli kodları yazar.
Kod incelemesi (Code Review): Kod tamamlandıktan sonra, diğer kıdemli geliştiriciler ya da proje yöneticileri kodu gözden geçirir. Bu inceleme süreci, hataları bulmak, güvenlik açıklarını tespit etmek ve kodun kalitesini artırmak için yapılır.
Test Süreci: Kod, sadece insanlar tarafından gözden geçirilmekle kalmaz, aynı zamanda otomatik testler de uygulanır. Google, kod tabanında ciddi bir hata olmamasını sağlamak için sürekli entegrasyon ve test süreçlerini kullanır.
Onay: Kod incelemesi ve testler başarılı olursa, kod ana kod tabanına eklenir.
Bu süreç, müdür seviyesindeki kişilerin manuel bir onayını gerektirmeyebilir. Genellikle yazılım ekiplerinde, lider geliştiriciler ve proje yöneticileri bu tür kararları alır.
3. Otomatik Derleme ve Yayınlama Süreci (Continuous Integration / Continuous Deployment)
Google gibi dev şirketler, Sürekli Entegrasyon (Continuous Integration - CI) ve Sürekli Yayınlama (Continuous Deployment - CD) sistemleri kullanır. Bu sistemler, kod değişikliklerinin sürekli olarak test edilip ana kod tabanına entegre edilmesini ve otomatik olarak dağıtıma geçilmesini sağlar.
CI/CD sistemleri, geliştirici kodu sisteme eklediğinde, kodun doğru çalıştığını ve diğer parçalarla uyumlu olduğunu test eder. Bu sayede her kod parçası sorunsuzca ana kod tabanına eklenir.
4. Modüler Yapı
Bu kadar büyük bir kod tabanını yönetmek için Google, modüler bir yapı kullanır. Bu modüler yapı sayesinde her geliştirici, devasa sistemin sadece belirli bir bölümünde çalışır. Örneğin, Google’ın arama motoru, haritalar, Gmail, YouTube gibi servisleri ayrı modüllerdir ve her modül kendi yazılım ekipleri tarafından yönetilir.
Bağımsız Takımlar: Her ekip, kendi sorumluluğundaki kod tabanı üzerinde çalışır ve yalnızca ihtiyaç duyduğu diğer bölümlere entegre olur. Böylece herkes kendi koduna odaklanırken, tüm sistemi bozma riski azalır.
5. Güvenlik ve Gizlilik
Google, milyonlarca kullanıcının kişisel verilerini işlediği için kodlara erişim konusunda çok sıkı güvenlik önlemleri alır. Geliştiricilerin kodu değiştirme veya görme yetkileri, işlerinin gerektirdiği kadardır. Güvenlik politikaları ve araçları, hassas bilgilerin erişimini sınırlar.
Özetle:
Herkes tüm koda erişemez: Geliştiriciler yalnızca sorumlu oldukları modüllere veya bileşenlere erişebilir.
Kod tamamlama: Geliştiriciler görevlerini bitirdiklerinde kodlarını bir "branch" üzerinde tamamlarlar, sonra kod gözden geçirilir ve test edilir.
Onay: Kod gözden geçirilip testlerden geçtikten sonra, kod ana kod tabanına entegre edilir.
Otomasyon: CI/CD sistemleri sayesinde derleme ve dağıtım süreci genellikle otomatiktir ve manuel müdahale gerekmez.
Bu süreçler, yazılım geliştirme sürecini düzenli ve güvenli hale getirirken aynı zamanda yazılım kalitesini de yüksek tutar.
her geliştirici tüm kodlara erişemez hangi projede çalışıyorsa sadece o projenin kodlarını görebilir. İşler genelde sprint dedikleri 2 hafta ya da aylık şekilde belirlenir, kişilere atanır, sen ilgili işin kodunu yazarsın, "müdürüm bitti benimki" demezsin :) ama sistemde süreci ilerletince (jira) herkes bitirdiğini anlar. review (kod incelemesi) yapar daha tecrübeli yazılımcılar, sonra testçilere gider, testler de ok olursa, o sprintte senlik bir iş kalmaz. Sonra belirli aralıklarla senin yaptığın değişikliğin de dahil olduğu güncellemeler çıkar, müşteriler de bu sayede güncel uygulamaya erişirler. Google'de birebir böyledir mi bilmiyorum ama bunun benzeri süreçlerdir.
