Versiyon Kontrol Sistemleri
Windows ve Unix yazılım geliştirme faaliyetlerinde çalışan kişilerin bakış açısından bakacak olursak, modern konfigürasyon yönetimi çeşitli etkilerin ortaya çıkması ile evrim geçirmiştir. Orijinal dosya-odaklı (file-oriented) versiyon kontrol sistemleri (Örneğin SCCS, RCS [Tic85] ve daha sonraki tarihlerde ortaya çıkan PVCS ve Visual SourceSafe gibi) hızlı bir şekilde PC ve Unix yazılım geliştirme toplulukları arasında güçlü bir konuma gelmiştir. Bu sistemler basit, dosya-odaklı, delta-tabanlı bir arşivleme ve uyumluluk kontrolü sağlamıştır.
Ancak söz konusu bu dosya-tabanlı versiyonlama sistemleri yalıtılmış çalışma alanları, uygulama yapısının izlenmesi ve yeniden üretilebilir build’ların oluşturulması gibi konfigürasyon yönetiminin geniş bir alana yayılan konularına hiç değinmemiştir. Bundan ötürü bir çok kuruluş, temel bir konfigürasyon yönetimi sağlayabilmek için, bu sistemlerin üzerinde (çoğunlukla Unix shell scriptler veya DOS batch dosyaları kullanmak suretiyle) bir katman oluşturmak zorunda kalmıştır.
Kod Yönetim Sistemleri
DSEE [Leb85] ve NSE [Cou89] gibi ilk geliştirici odaklı kod yönetim sistemleri 1980’lerin yarısıyla sonuna doğru ortaya çıkmaya başlamıştır. Bu sistemler yazılım geliştiricilerine önemli ölçüde fayda sağlamakla birlikte yine de bir çok projenin ihtiyaç duyduğu yönetim kontrolü veya raporlama yetisi sağlayamamıştır.
Konfigürasyon Yönetimi Sistemleri
Kod yönetim sistemlerinin ilerlemesine paralel olarak, mühendislik ve savunma sanayii toplulukları tarafından meydana getirilen her şey ile bunların meydana gelmesinde kullanılan araç ve proseslerin tüm yönleri ve unsurları ile kayıt altında tutulmasına yönelik -metrik cetvel (bill-of-materials) olarak da bilinen- prosedürler tespit edilmiştir. Bu uygulama, standartların belirlenmesi yetkisine sahip Amerikan Savunma Bakanlığı (DoD) ve IEEE (Elektrik ve Elektronik Mühendisleri Enstitüsü) tarafından formüle edilmiştir ve bunu takiben konfigürasyon yönetim sistemleri daha önceden elle yürütülen bu kayıt sürecini otomatik hale getirmiştir.
İlk konfigürasyon yönetim sistemleri güçlü bir kontrol sağlarken bu sistemler, yazılım geliştiricileri tarafından aynı zamanda rahatsızlık verici, engelleyici ve haddinden fazla kısıtlayıcı olarak nitelendirilmiştir. Öyleki, bu sistemler tipik olarak bir geliştirme sürecinin omurgası ve geliştirme sürecinde kullanılan bir kolaylık olmak yerine genellikle nihayi sonuçların arşivlenmesi amacıyla kullanılmıştır.
IT sektöründe mainframe alanında faaliyet gösteren firmaların da modern konfigürasyon yönetimine katkısı olmuştur. Bu firmalar, merkezi bilgisayar sistemleri üzerinde çalışan büyük ölçekli yazılım geliştirme ekiplerine ilişkin meselelerle yıllarca boğuştuktan sonra merkezi veri havuzlarını kullanan araçlar geliştirmiştir. Bu araçlar ayrıca daha ziyade büyük ölçekli IT kuruluşlarının ihtiyacı olan güçlü bir kontrol yetisi de sağlamıştır. Merkezi, zamanpaylaşım-odaklı (timeshare-oriented) CM (Konfigürasyon Yönetimi) faaliyetlerinde kullanılan teknolojinin çok az bir kısmı bu yeni, farklı mekanlara dağılmış olarak faaliyet gösteren bilgisayar dünyasına uygulanmış ise de kavramların birçoğu geçerliliğini korumuştur.
Modern konfigürasyon yönetim sistem tasarımcıları çok kısa bir süre içerisinde yukarıda belirtilen tüm zümre ve kişilerin hala yapabilecekleri birçok katkının bulunduğu gerçeğini kavramışlardır. Zorluk ise, yeniden üretilebilirlik ile mühendislik ve mainframe-odaklı sistemler üzerinde kullanımı kolay ve hiç bir şekilde kullanılması rahatsızlık yaratmayan yazılım geliştirici-odaklı sistemler vasıtasıyla kontrol sağlayan CM sistemlerinin geliştirilebilmesinde yatmaktadır.
Entegre Değişiklik ve Konfigürasyon Yönetimi
Bu zaman aralığında iki anahtar faktör ortaya çıkmaya başlamıştır:
Bunlardan ilki uygulamaların giderek daha büyük ve karmaşık bir hale gelmesidir. Legacy sistemlerin sayısı artmaya başladıkça yazılım değişikliklerinin izlenmesi ihtiyacı da kritik bir hal almaya başlamıştır. İlk geliştirilen değişiklik izleme sistemleri sınırlı bir başarı elde etmiştir; çünkü bunlar tipik olarak, kaynak kodunu idare eden sistemlerden bağımsız şekilde çalışmaktaydı: Buna göre, kaynağı yöneten ayrı bir sistem ve kaynaktaki değişiklikleri yöneten başka bir sistem bulunmaktaydı.
İkinci faktör ise, şirketlerin konfigürasyon yönetim araçlarını sadece, kendi proses ve iş-akışı katmanlarını (layers) sistemin tepesine yerleştirmek amacıyla kullanmak ihtiyacını hissetmeleridir. Bu, konfigürasyon yönetimi ve prosesi arasında yakın bir ilişki bulunması ile yazılım geliştirme ekiplerinin çalıştıkları ortamda bir eksiklik hissetmelerinden kaynaklı olarak gerekli hale gelmiştir.
Dahili bir proses ve iş-akışı unsurlarını barındıran bir konfigürasyon yönetim sistemini oluşturmanın güçlüğü tek bir boyutta üretilen bir sistemin tüm geliştirme süreçlerinin ihtiyaçlarına cevap verememesi gerçeğinden kaynaklanmaktadır. Her bir takımın kendine özgü proses gereklilikleri ile göz önünde bulunduracağı noktalar bulunmaktadır. Bu sebeple, konfigürasyon yönetim sistemleri, özelliklerin (attributes) ilave edilebilmesi, tetikleyicilerin (triggers) harekete geçirilmesi ve objelerin linklenmesi gibi birincil olarak öğrenilmesi gereken proses “kancalarını (hooks)” kendine dahil etmiştir. Ancak, genel bir proses yönetim çözümü olmadan sadece bu teknolojinin sağlanması:
-
Geliştirme ekiplerinin (hâlâ) kendi konfigürasyon yönetim çözümlerini konfigürasyon yönetim teknolojisi üzerine inşaa etmeye mecbur olmaları, ve
-
Geliştiricilerin, kendilerini zorlayan bir mekanizmanın bulunmaması sebebiyle, geliştirme sürecine uymama yoluna gidebilecekleri, anlamına gelmektedir.
Bunun bir sonucu olarak, modern Konfigürasyon Yönetim Teknolojisinin değişiklik izleme, iş-akışı ve proses teknolojisi ile birleşerek tek bir esnek ve konfigüre edilebilir çözüm oluşturması ihtiyacından, gelişmiş Değişiklik ve Konfigürasyon Yönetimi ortaya çıkmıştır.
Günümüz Değişiklik ve Konfigürasyon Yönetim Sisteminin Tanımlanması
En gelişkin değişiklik ve konfigürasyon yönetim sistemleri bünyelerinde modern konfigürasyon yönetimi, proses yönetimi ve değişiklik izleme özelliklerini barındırarak merkezi veya global bazda dağıtık şekilde çalışan geliştirme ekipleri için son derece sıkı sıkıya entegre olmuş bir çözüm sunmaktadır.
Günümüz yazılım geliştirme ortamında karşılaşılan güçlükler ile başa çıkabilmek açısından değişiklik ve konfigürasyon yönetim sistemlerinin altı ayrı, aynı zamanda birbiri ile ilintili unsura sahip olması gerekmektedir:
-
Obje yönetimi
-
Proses yönetimi
-
Çalışma alanı yönetimi
-
Yapı yönetimi (Build Management)
-
Değişiklik izleme (Change Tracking)
-
Ayrık Takımlarla geliştirme faaliyeti yürütebilme kabiliyeti
Obje Yönetimi (Object Management)
Obje yönetim sistemi modern konfigürasyon yönetim sisteminin temel taşıdır. Bir konfigürasyon yönetim sisteminin en temel seviyedeki sorumluluğu objeler ile objeler arasındaki ilişkileri idare etmektir. Bunu yaparak, bir araya gelmiş önemli obje toplulukları (yani konfigürasyonlar) idare edilebilir ve objelerin spesifik versiyonları seçilebilir. Objeler ayrıca, oluşturulabilir, kontrol edilebilir ve paylaşılabilir, ve objeler üzerinde yapılan değişiklikler izlenebilir.
Obje yönetim sistemi, objelere erişimi kontrol etmenin yanı sıra değişiklikleri, paralel versiyonları, varyant dal (branch) versiyonlarını ve obje birleşmelerini de eş zamanlı olarak idare eder. Bir obje yönetim sistemi bu sebeple, tüm obje tiplerinin versiyon kontrolünü yapabilmelidir: sadece kaynak dosyalarını değil ve fakat aynı zamanda dizinleri, kütüphaneleri (libraries), executable’ları, dizaynları, belgeleri (documents), schedule’ları, test case’lerini, test sonuçlarını, yardım verilerini, makefile’ları, konfigürasyonları ve bunun gibi diğer nesnelerin de kontrolünü yapabilmelidir. Desteklenen tiplerin (support types) çeşidi genişletilmiş olmalı ve kontrol edilmekte olan davranış (behaviors) çeşitleri için de uygun destek sağlanmalıdır. Buna ek olarak bir objenin sadece kaynak veya veri dosyasını barındırmaya ihtiyacı yoktur. Bir obje ayrıca versiyon etiketi, versiyon sahibi, statü, sürüm ve hedef platform gibi objeleri tarif eden bilgileri (veya özellikler) barındırması da gerekmektedir. Sistemi kullanan ekiplerin, takip ettikleri prosesin desteklenmesi gerektiği hallerde dinamik olarak ilave özellikler yaratabilmeleri gerekmektedir.
Proses Yönetimi (Process Management)
Proses yönetim sistemi objelerin kurum içerisinde geliştirme biriminden test birimine daha sonra da sürüm birimine (release management) gönderilmesini sağlamaktan sorumludur. Objelerin bu şekilde gönderilme süreci kurumdan kuruma büyük farklılıklar gösterebilir, hatta bazen aynı kurum içerisinde bulunan proje ekiplerinde bile farklılıklar görülebilir.
Proje yönetim sistemi, bir proje ekibi nasıl bir geliştirme prosesi tanımlamış ise bu prosesin gereklerinin tam olarak yerine getirilmesini sağlamak için obje yönetimi ile yakın bir işbirliği içerisinde çalışır. Bunun sonucu olarak, CM sistemi herhangi bir prosesi zorunlu kılmak yerine geliştirilmekte olan bir bileşene ait proses modelini ayrıştırarak bunun uygulanmasını sağlayacak esnekliğe sahip olmak zorundadır. Bu sistem ayrıca farklı ekiplerin, hızlı uygulama geliştirme (rapid application development) ve daha resmi prosedürlere (waterfall gibi) göre belirlenen prosesler gibi birbirinden neredeyse tamamen farklı prosesleri kullanabilmesine olanak tanımak zorundadır.
Görev-tabanlı (task-based) bir iş-akışı da (workflow) -mantıksal değişikliklerin yönetilmesi ile her bir göreve ilişkin fiziki dosya değişikliklerinin izlenmesini sağlayan ön sezgili bir süreç de- idealdir. Bu, sistemin bir baseline’ına belirli bir takım taskların eklenmesi ile konfigüre edilebilmesini sağlamaktadır. Gerekli olduğu hallerde görevler eklenebilir veya çıkarılabilir. Görev-tabanlı CM sistemlerinin ayrıca test aşamasından önce, paralel versiyonlar ve kayıp veya kısmen eklenmiş tasklar gibi yazılım çakışmalarını (conflict) tespit edebilmesi gerekmektedir. Buna ek olarak, proses yönetim sisteminin güvenlik, erişim kontrolü ve rol tabanlı ara yüzler sağlaması da gerekmektedir ki bu sayede farklı kullanıcılar farklı verilere ve kendilerine atanan rollere uygun fonksiyonlara erişebilsinler.
Çalışma Alanı Yönetimi (Work Area Management)
Herhangi bir gelişkin konfigürasyon yönetim sisteminin her bir kullanıcıya, ekibin başka bir üyesinin yapabileceği bir değişiklikle kendi yaptığı işleri bozma endişesi olmadan güven içerisinde çalışabileceği başkalarından izole edilmiş bir çalışma ortamını sağlaması gerekmektedir. Sistemin, beklenmedik değişikliklerden etkilenmeme garantisi sağlaması gerekmektedir, fakat sistem aynı zamanda kullanıcıyı diğer ekip üyelerinden de izole etmemelidir. Geliştiriciler değişiklikler üzerinde birlikte çalışabilmeli, diğer kullanıcıların yaptığı değişikliklerin hazır hale gelmesini takiben bu değişiklikleri kendi çalışma ortamlarına aktarabilmeli ve değişiklik yapmadan önce ve sonra paralel versiyonlar arasındaki muhtemel çakışma sorunları hakkında ikazlar alabilmelidir.
Çalışma alanı yönetim sistemleri, entegrasyon testleri, sistem testleri veya kişisel deneme gibi spesifik amaçlarla çalışma alanı yaratılmasını kolaylaştırmalıdır. Belirli
bir çalışma alanı için hangi objelerin seçilebileceğini belirleyen kriterler kolay bir şekilde tarif edilebilmelidir (örneğin “sürüm 4.1 branch’ı üzerindeki Windows platformunda tamamlanan en son tarihli görevleri ver” gibi).
Çalışma alanı yönetim sistemi gerektiğinde, programların versiyonları ve bu konfigürasyonlardan oluşturulan kütüphaneler (libraries) de dahil olacak şekilde eski tarihli konfigürasyonları yeniden üretebilmelidir.
Yapı Yönetimi (Build Management)
Bir sürümün oluşturulabilmesi için sadece kaynak objeleri ile sürümleri oluşturan taskların kontrol edilmesi yeterli değildir. Gerçekten iyi inşaa edilmiş bir konfigürasyon yönetim sisteminin ayrıca yapı (build) ürünleri (türetilen objeler) ile bu ürünlerin üretilmesinde kullanılan yapı proseslerini de kontrol etmelidir.
Modern konfigürasyon yönetim sisteminin en kritik gerekliliklerinden birisi yeniden üretilebilirliktir (reproducibility). Sistem eski konfigürasyonları ve ürünleri bularak ürünlerin nasıl üretildiğini inceleyebilmeli ve yeni ürünleri (Örneğin, yamalar için) söz konusu bu eski konfigürasyonlara dayanmak suretiyle üretebilmelidir. İdeal olarak ise, ürünleri oluşturan unsurların tam ve kesin bir listesini veren ve bağımlılıkları (dependencies) otomatik olarak hesaplayan bir metrik cetvelin (Bill-of-Materials) oluşturulması ve idare edilmesi gerekmektedir.
Yapı sistemi, konfigürasyon sisteminin dahili bir parçası olmalıdır. Bu sistemin önemli yetenekleri arasında varyantlarla ilgili özelliklerin belirlenebilmesi ve okunabilmesi, ürünlerin yaratılması ve tescili, yeniden kullanılabilir ürünlerin paylaşımı ve ürün iş-akışlarının nasıl çalıştığının anlaşabilmesi yer almaktadır. Bundan da öte, yapı sistemi yük-dengeli, paralel ve farklı noktalara dağıtılmış yapıların desteklenmesi suretiyle network kaynaklarını kullanabilmesi de gerekmektedir.
Değişiklik İzleme (Change Tracking)
Proje verilerinin yönetimi konfigürasyon yönetim sistemleri için en temel gerekliliktir. Ancak bununla aynı öneme haiz bir başka unsur ise proje dosyaları üzerinde yapılan değişikliklerin yönetilmesidir.
Konfigürasyon yönetim sistemi değişikliklerin yapılması için farklı prosedürleri destekleyebilecek kadar esnek olmak zorundadır. Bazı ekiplerde herhangi bir dosya üzerinde geliştirici (developer) tarafından herhangi bir zamanda değişiklik yapılabilmesi gerekirken kimi ekipler de herhangi bir değişiklik yapmadan önce bir onay sürecinden geçmeleri gerekebilmektedir. Değişiklik isteklerinin incelenebilmesi ve bu taleplerin ilgili birimlere aktarılması yeteneği, kimlerin bu değişiklik isteklerine (change requests) onay vereceği veya değişiklik talebini ilgili birime aktaracağı gibi hususlar oldukça önemlidir. Buna ek olarak sistemin, örneğin gerçek görev süresi ile tahmini görev süresi, verifikasyon notları, değişiklik tarifi ve ekler gibi bilgilerin hangisinin hangi safhada gerekli olduğunu belirleyebilecek kadar esnek olması gerekir.
Değişiklik izleme sistemi değişiklik talebi ile bu talep üzerine yürütülen taskları ve bu taskların yürütülmesi sırasında değiştirilen fiziksel dosyaların tam olarak izlenebilmesini (full traceability) sağlamalıdır. Ek olarak geriye yönelik yani orijinal gereksinime ya da müşterinin değişiklik isteklerine yönelik tam izlenebilirlilik de sağlanmalıdır. Ayrıca, değişiklik izleme sistemi görev-tabanlı iş-akışı ile entegre edilerek kullanıcıya, münferit dosyalar yerine mantıksal (logical) değişiklikler üzerinde çalışma olanağı tanımalıdır.
Ayrık Takımlarla Geliştirme Faaliyeti Yürütebilme Kabiliyeti
Konfigürasyon yönetim sistemi merkezi, uzaktan kontrollü ve farklı noktalara dağılmış halde yürütülen tüm geliştirme faaliyetlerini desteklemelidir. Yerel ekip üyeleri merkezi geliştirmeyi oluşturmaktadır. Uzaktan kontrollü geliştirme, görev yeri dışında çalışan (off-site) veya yerel konfigürasyon yönetim sistemine bağlı olmadan (offline) çalışan ekip üyelerini desteklemektedir. Farklı noktalara dağılmış halde yürütülen geliştirme faaliyetleri ise her zaman için bir networke bağlı olma zorunluluğu olmadan farklı görev yerlerinden genel dosyalar üzerinde çalışan ekipleri ifade etmektedir. Bunların her üçü de son derece önemlidir.
Ayrık takımlarla geliştirme faaliyetleri için farklı lokasyonlarda bulunan veri havuzları (repositories) senkronize edilerek her iki mekanda bulunan ekip üyelerinin en son dosyaları ve proje yapay ürünlerini (artifacts) görebilmeleri, yapılandırabilmeleri ve kullanabilmeleri sağlanmalıdır. Her ne kadar fiziki veri havuzunun sayısı birden fazla olsa da CM tek bir mantıksal havuz görüntüsü sunarak birbiriyle ortaklaşa yürütülen geliştirme faaliyetlerine olanak tanımalı ve yazılımın mevcut durumunun görülebilmesini sağlamalıdır.
Buna ek olarak, ekipler projenin genelinden tek bir taska (ve bununla ilgili dosyalara), bir değişiklik isteğine (ve bununla ilgili tasklar ve dosyalara) ve tek bir dosyaya varıncaya kadar tüm veritabanı üzerinde hangi verilerin transfer edildiğini kontrol edebilmeye ihtiyaç duymaktadır. Bu, kurumda kimlerin nelere erişip kullanabildiğinin kontrolünü garantiler.
Bunların dışında, burada daha önce anlatılan tüm özeliklerin, yetilerin, görev-tabanlı iş-akışı ve değişiklik isteklerinin eksiksiz bir şekilde izlenebilmesi de dahil olmak üzere sadece fiziki bir veri havuzunu değil global, mantıksal bir veri havuzunu da desteklemesi zorunludur.