Yazılım Notları
Bilgi Paylaştıkça Çoğalır...

Release & Deployment Management

Uluslararası kabul görmüş standart ve çerçevelerin (ISO 27001, 27005, 20000, 31000, ITIL V3, CMMI vb gibi) yazılım geliştirme süreçlerindeki etkisi göz ardı edilemez. Söz konusu standartlara uyumlaştırma sürecine girdiğinizde Yazılım Geliştirme, Test ve Production ortamlarının birbirinden ayrılması gerektiği açık bir şekilde ifade edilmektedir. Bununla da kalmayıp, söz konusu ortamların yönetilmesinden ve bu ortamlarda uygulanacak işlerin yürütülmesinden sorumlu personelin de farklı kişilerden oluşması istenmektedir. Görevler ayrılığı ilkesine göre, yazılım geliştirmede görev alan personel ne test sürecinde ne de Release & Deployment sürecinde yer almalıdır.

Release & Deployment Management

 

Uluslararası kabul görmüş standart ve çerçevelerin (ISO 27001, 27005, 20000, 31000, ITIL V3, CMMI vb gibi) yazılım geliştirme süreçlerindeki etkisi göz ardı edilemez. Söz konusu standartlara uyumlaştırma sürecine girdiğinizde Yazılım Geliştirme, Test ve Production ortamlarının birbirinden ayrılması gerektiği açık bir şekilde ifade edilmektedir. Bununla da kalmayıp, söz konusu ortamların yönetilmesinden ve bu ortamlarda uygulanacak işlerin yürütülmesinden sorumlu personelin de farklı kişilerden oluşması istenmektedir. Görevler ayrılığı ilkesine göre, yazılım geliştirmede görev alan personel ne test sürecinde ne de Release & Deployment sürecinde yer almalıdır.

 

Geliştirilen bir yazılımın devreye alınması süreci yaklaşık olarak aşağıdaki gibidir:

1.      Veritabanı yedeği alınır.

2.      Son sürüm dosyalarının bir yedeği alınır.

3.      Eğer yazılımın dış bağımlılıkları varsa bunlarla ilgili notlar, açıklamalar, dokümantasyon sağlanır.

4.      Yeni sürüme bir numara verilir.

5.      Veritabanında (varsa) değişiklik scriptleri oluşturulup uygulanır.

6.      Yazılımın dış bağımlılıklarındaki değişiklikler uygulanır.

7.      Yeni sürüm dosyaları yayımlanır.

Bu süreç genelde tam olarak uygulanmaz. Ya restore edilebilir bir Veritabanı yedeği yoktur, ya bu yedeğin isimlendirmesi ileri ki bir tarihte anlaşılabilir değildir. Ya devreye alınan son sürüm, bir önceki sürüm dosyalarının üzerine yazılır, vb. gibi.

PROBLEM:

Yukarıdaki gibi bir sürecin uygulanmaması aşağıdaki riskleri barındırır:

1.      Sürümler arasında gerçekleştirilen değişikliklerin sebeplerini tespit edememe

2.      Herhangi bir sebepten dolayı bir önceki sürüme dönülmesi gerektiğinde bu işi başaramama

3.      Hesap verebilirlikte ilgili riskler

4.      Yukarıda bahsedilen standart ve çerçevelerin gerektirdiği şekilde versiyon takibini yapamama

5.      Yazılım yaşam döngüsünü etkin ve etkili bir şekilde yönetememe

6.     

 

ÇÖZÜM:

Release & Deployment sürecini tam olarak uygulamak için şöyle bir yazılım olsa:

1.      Windows tabanlı bir uygulama

2.      Yazılım geliştiriciler Veritabanı yedeğini bu yazılım üzerinden bir dosya paylaşım sunucusuna alsalar

3.      Yazılım geliştiriciler devreye alınacak uygulamalarıyla ilgili dosyaları da bu yazılım üzerinden dosya paylaşım sunucusuna upload etseler

4.      Yazılımın yeni versiyon numarası ile ilgili açıklamalarını da kaydetseler

5.      Yazılımın bu versiyonunun geliştirilmesini gerektiren dokümantasyonu da sisteme yükleseler

6.      Ve yazılımın yeni versiyonunun devreye alınması için Sürüm ve Devreye Alma Yöneticisi’ne sistem üzerinden bir talep gönderseler.

7.      Yönetici, bu talep doğrultusunda, devreye alınacak yazılımın yeni versiyon numarası ve gerekiyorsa açıklamaları sisteme kaydetse ve [devreye al] sürecini başlatsa.

a.      Sistem önce, uygulamayı IIS üzerinden durdursa

b.      Sonra devreye alınacak uygulamanın son versiyonunun Veritabanı yedeğini alsa ve dosya paylaşım sunucusuna kaydetse

c.      Daha sonra, devreye alınacak uygulama dosyalarının bir yedeğini alıp, bunları da dosya paylaşım sunucusuna kaydetse

d.      Sistem, yedekleri alınan bu dosyaların ve Veritabanı backuplarının dosya yollarını, bu uygulamanın versiyonu ile ilişkilendirerek kendi veritabanına kaydetse

e.      Sisteme, yazılım geliştiriciler tarafından yüklenen Veritabanı yedekleri restore edilse

f.       Sisteme yazılım geliştiriciler tarafından yüklenen yazılım uygulaması ile ilgili dosyalar (publish edilecek) da IIS üzerinden ilgili dizine yüklense ve önceki versiyonları silse

g.      IIS üzerinden uygulamayı yeniden başlatsa

8.      Herhangi bir sebepten dolayı bir önceki sürüme dönülmesi gerektiğinde ise yönetici [şu versiyona git] dediğinde

a.      Sistem IIS üzerinden uygulamayı durdursa

b.      Veritabanının o anki yedeğini alarak dosya paylaşım sunucusuna kaydetse

c.      Son versiyonun publish dosyalarını da alıp yine dosya paylaşım sunucusuna kaydetse

d.      Önceki sürümle ilişkili olan Veritabanı yedeğini, dosya paylaşım sunucusunda bularak restore etse

e.      O sürümle ilişkili olan publish dosyalarını da IIS üzerinden ilgili dizine yüklese

f.       IIS üzerinden uygulamayı yeniden başlatsa

9.      Bu şekilde, versiyonlar arasında geçiş işlemi tam olarak otomasyona bağlanmış olur(Verisyonlar arasındaki veri kaybı konusu çözümlenmeli)

10.   Sürüm ve devreye alma yöneticisi, bir uygulamanın tüm versiyonları, bunlarla ilgili dokümantasyonu anlık olarak raporlayabilir.

11.   Hatta, yazılım talep süreci de bu sistem üzerinden gerçekleşirse yazılım yaşam döngüsü sistem üzerinden takip edilebilir olacaktır:

a.      Yeni yazılım talebi sistem üzerinden alınır

                                                    i.     Talebi yapan birim, analiz toplantılarına katılacak konuyla ilgili son kullanıcılar

                                                   ii.     Toplantı zamanı

                                                  iii.    

b.      Analiz toplantısı düzenlenir ve toplantı notları sisteme kaydedilir

c.      Sistem üzerinde, analiz dokümanı hazırlanır (belirlenmiş şablonlar yoluyla) ve bunlar analiz yapılan kişilere sistem üzerinden mail atılır. Bu mailleşmeler sistem Veritabanında kayıtlı olacağı için, bir yazılımla ilgili yapılan tüm çalışmalar rahatça raporlanabilir.

d.      Gereksinim dokümanı sistem tarafından ürettirilir

e.      Tasarım dokümanı ya sistem dışında üretilerek upload edilir, ya da sistemin bu işleri yapması için de düzenleme yapılabilir.

f.       Geliştirilen kaynak kodlar, veri tabanı yedekleri vs. test ve devreye alma aşamalarında sisteme yüklenir.

g.      Test senaryoları sistem üzerinden oluşturulabilir ve test ekibine gönderilebilir.

h.      Uygulamayla ilgili penetrasyon testleri, yük testleri gibi çalışmalarla ilgili dokümanlar sisteme yüklenebilir.

i.       Test ekibinin, yaptıkları testlerde karşılaşacakları sorunları anlık olarak iletebilecekleri bir test geri bildirim formu(sayfa) sistem üzerinden doldurulur. Bu şekilde, yapısallaştırılmış verinin toplanması yoluyla, test sonuçları üzerinden çok detaylı analizler yapılabilir ve bunlar raporlanabilir.

j.       Test geri bildirimlerine karşı alınan aksiyonlar sistem üzerinden takip edilebilir.

k.      Devreye alma süreci ise yukarıda anlatıldığı şekilde yönetilmiş olur.

 

GÜZEL OLMAZ MI?

 

 

Banka Hesap Numaralarınızı, IBAN Numaralarınızı bir kere telefonunuza kaydedin. İhtiyaç duyduğunuzda elinizin altında olsun.

Banka Hesaplarım

En Güzel Sözler Uygulaması İçin


En Çok Rating Alanlar
Ana Sayfa       Arama       Valid CSS!