Teknoloji Göç Stratejileri hakkında eksiksiz bir rehber: (Bölüm 1 – Giriş)

Her geçen gün gelişen yeni teknoloji ile eski teknolojiler modası geçmiş hale geliyor. Günümüz piyasasında ayakta kalabilmek için her şirketin güncel kalması gerekli hale geldi. Kullanıcılarına çeşitli hizmetler ve platformlar sunan herhangi bir şirket, günlük yükseltme teknolojileriyle başa çıkmaya hazır olmalıdır. Böyle zamanlarda göç devreye giriyor. Bir şirket her zaman yeni ve daha iyi bir platforma geçebilir. Şimdi, insan göçün ne olduğunu düşünebilir. Cevap kısa ve aynı zamanda biraz karmaşık. Göç, bir yerden başka bir yere göç etmek anlamına gelen teknoloji dışı mugglelar için çok basit bir terimdir. Ancak bizim gibi teknoloji sihirbazları söz konusu olduğunda, biraz farklı bir anlamı var. O halde ilk adımı atalım ve göçü teknik terimlerle anlayalım. Göç, mevcut platformdan başka bir platforma geçmek anlamına gelir. Çoğu durumda, geçiş daha iyi bir çalışma ortamı ve kullanıcı deneyimi sağladığı için daha iyi bir platforma gerçekleşir. Bazen güvenlik endişeleri de göçe neden olabilir. Pek çok göç türü vardır ve bilmek isteyebileceğiniz en çok konuşulan göç konularından bazıları şunlardır:

1. Teknoloji Göçü
2. Ön Uç Teknoloji Geçişi
3. Arka Uç Teknoloji Geçişi
4. CMS yerleşik web sitesi Taşıma
5. Veritabanı Taşıma
6. Etki Alanı ve Barındırma Sunucusu Geçişi

Teknik terimlerle göç, hayal edebileceğinizden çok daha geniş bir konudur. Tüm geçiş konularını ve türlerini tek bir blogda ele almak biraz zor. Bu nedenle bu konu farklı bölümlere ayrılarak göçün önemi ve türleri anlatılmıştır. Bunları gelecek bloglarda okuyabilirsiniz.

Taşıma çok önemli bir iştir ve ne zaman taşınacağınız, nasıl taşınacağınız, göçün kapsamının tanımlanması vb. sorular sizi rahatsız ediyorsa, zihninizi boşaltmak için bu blogu okumaya devam etmek isteyebilirsiniz.

Neden Göçe İhtiyaç Var?

• Uzun süredir üzerinde çalıştığınız mevcut teknolojiniz artık iş gereksinimlerinizin beklentilerini karşılayamaz hale geldiğinde.
• Teknoloji eskidiğinde ve eski sürüm için satıcı desteği de mevcut olmadığında.
• Müşterileriniz sizin için önemli olduğunda ve kendi alanınızda en üstte olmanız gerektiğinde.
• Açık kaynaklı bir platforma geçerek mevcut yığının devasa lisanslama maliyetini artık istemiyorsanız.

O zaman, Göç en iyi seçeneğiniz olacaktır. Göç karmaşık bir süreçtir ve çok fazla planlama gerektirir.

Göç sürecine doğru ilk adım, göç sürecini sorunsuz bir şekilde gerçekleştirebilecek bazı tanım ve temel kurallar belirlemeniz gerektiğidir. Projenin ihtiyacına bağlı olarak:

• Öncelikle, taşınması gereken projenizin veya uygulamanızın mevcut durumunu analiz etmeniz gerekir.
• Hesaplanmış risklerin ve geçiş sırasında oluşabilecek olası çözümlerin bir yol haritasını hazırlayacaksınız.
• Projenin tüm gereksinimlerini karşılayan uygun bir teknoloji seçmeniz gerekiyor.
• Ardından, geçiş sürecini yürütmek için uygun bir plana ihtiyacınız olacak
• Sonunda, geçiş işlemi tamamlandığında, uygulamanın yeni platformda beklendiği gibi çalışıp çalışmadığını kontrol edin.

Göçün planlama aşamasına geçmeden önce aklınızda bulundurmanız gereken birkaç nokta var.

• İş sorununa bağlı olarak geçişin planlama aşamasından önce bir proje bütçesi ve zaman çizelgesi belirleyin.
• Mevcut herhangi bir sistemden yenisine geçmek isteyen herhangi bir yeni müşteri için saatlik ücretler veya haftalık ücretler gibi bir çalışma modeli belirleyin. Gelecekteki blog serilerinde tartışacağımız birkaç gri alan var ve bunlarla ancak yeni bir geliştirme ekibi çalışmaya başladığında karşılaşılabilir. Geçiş, herhangi bir yeni ekip için sabit bir tahmini iş ile ele alınamaz.
• Müşteri teknik olmayan bir kişiyse, geçişin planlama aşamasından önce geçişin kapsamını belirten bir sözleşme imzalamanız her zaman önerilir veya müşteri ayrıca geliştirme ekibiyle bağlantı kurabilecek sözleşmeli bir proje yöneticisi de işe alabilir.

Göç Kapsamını Tanımlayın

Geçiş projesi üzerinde çalışan ve mevcut sistemden habersiz olan herhangi bir geliştirici ekibi için müşteri, ekibin sistemin akışını anladığından emin olmak için yeni ekiple zaman geçirmelidir. Yeni ekip, mevcut sistemi analiz etmek ve bir geçiş planı oluşturmak için yeterli zaman ayırmalıdır. Bu arada, müşteri mevcut sistemle karşılaştığı iş sorunlarının neler olduğunu her zaman dile getirebilir.

Bir projenin kapsamını tanımlamak için müşteri, geçişi başarıyla tamamlamak için ayrıntılı bir proje gereksinimini paylaşmalıdır. Geliştiriciler ve müşteri, geçiş planıyla aynı sayfada olmalı ve gelecekteki tüm sorunlardan korunmak için geçişin tüm yönleri hakkında uygun bir tartışma yapılmalıdır.

Bazen, geliştirme ekibi, arka uç teknolojisinde eşlenen iş mantığının ayrıntılı belgelerini oluşturmayabilir. Geçiş aynı ekip tarafından yapılırsa büyük bir sorun yaratmaz, ancak geçiş yeni bir ekip tarafından yapıldığında belgeler gerçekten önemlidir. Bu nedenle, iş mantığının ayrıntılı bir dokümantasyonuna sahip olmanız şiddetle tavsiye edilir.

Asıl kapsam dışında kalan her türlü çalışmanın ek çalışma sayılacağını ve asıl bütçe dahil prim ücretine tabi tutulacağını kapsam belgenizde açıkça belirttiğinizden emin olun. Bu, gelecekte meydana gelebilecek olası Kapsam Sürünmelerini önlemenize yardımcı olacaktır.

Kapsam Sürüngenlerine Nasıl Hizmet Verilir?

Scope Creep'lerin nasıl ele alındığını anlamadan önce, size Scope Creep teriminden ve bunun geliştirme ekibini nasıl etkilediğinden bahsetmeme izin verin. Kapsam Kayması, zaman çizelgesinde uzatma veya proje bütçesinde artış olmaksızın projeye dahil edilen değişen teknik gereksinimlerin sonucudur.

Kapsam Sürünmelerine neden olan birçok neden vardır ve proje geçişinizde bu sürünmelerden kaçınmanız için çok yaygın nedenlerden bazıları aşağıda listelenmiştir.

• Proje gereksinimlerinin yanlış anlaşılması, geçişin sonraki aşamalarında geliştiriciler için sorun yaratan kapsam kaymasının arkasındaki en yaygın nedenlerden biridir.
• Son kullanıcıdan sık sık geri bildirim almak gibi tuzaklardan kaçının. Tüm geri bildirim noktalarını eğlendirmenin anlamı yok. Ama hiç geri bildirim almıyorsunuz gibi değil. Yalnızca en çok tekrar eden ve gösterişli olanları seçin.
• Tüm değişiklik taleplerini kabul etmek, ilk başta olumlu bir ilişki kurmaya yardımcı olabilir, ancak müşterinin projeden memnuniyetsizliği ile sonuçlanacaktır. Bu nedenle, bir geri bildirim veya değişiklik talebini kabul etmeden önce, bunun önceliğinden ve aciliyetinden emin olun ve son müşteriyi çabalar üzerindeki etkisi hakkında bilgilendirin.
• Mevcut teknolojiye eklenen yeni özellikler, pazardaki ekonomik değişiklikler, kişisel acil durumlar vb. gibi kontrolünüz altında olmayan proje kapsamını etkileyen sayısız faktör vardır, bu nedenle bu olasılıklara hazırlanmak daha iyidir.

Artık Scope Creep terimini anladığınıza ve sona eren olası nedenleri bildiğinize göre, geçiş projeniz kapsamında herhangi bir sürüngenden kaçınmanın en iyi yolunun önleyici plan olduğu açıktır. Yaptığınız tüm planlamalardan bağımsız olarak, proje gereksinimlerinizde gelecekteki her özellik değişikliği talebini doğru bir şekilde üstlenmenin olası bir yolu yoktur. Böyle zamanlarda, taşıma kapsamına ilişkin belgeler sizi kurtarabilir.

Teknoloji yığını seçimi

Bir geliştirici olarak önünüzde MongoDB'den MySQL'e, AngularJS'den React'e, MEAN yığınından LAMP yığınına ve Amazon AWS gibi bulut barındırma sunucularından Apache gibi kendi kendine barındırma sunucularına kadar birçok seçenek mevcut. Bu seçenekler herkesin kafasını karıştırabilir. Bu nedenle, geçiş için planlı bir teknoloji yığını seçmek geliştiricinin sorumluluğundadır. Gelecekteki her ihtiyaca da hazırlıklı olmalısınız.

Geçiş platformunu seçmek istiyorsanız ve yeni platformun gereksinimlerini net bir şekilde anlamıyorsanız, o zaman deneyimli ve karmaşık sistemlerde çalışmış bir Çözüm Mimarı tutabileceğiniz bir seçenek var. İdeal olarak, üçüncü taraf bir danışmanlık olacaktır, böylece müşteri Çözüm Mimarını kendi başına işe alabilir veya gelişmekte olan şirkete ödeme yapabilir. Bu, göç aşamasını planlamadan önce yapılması gereken görev üzerinde müzakere edilmeli ve kararlaştırılmalıdır.

Yeni platformun özelliklerinin denenmiş ve test edilmiş olduğundan emin olmanız gerekir. Kesinlikle, yeni platformun dezavantajlarını ve tuzaklarını bilen ilk kişi olmak istemezsiniz. Tüm verilerin güvenli bir şekilde korunduğundan ve diğer özelliklerin yeni bir platforma geçişten sonra fazla değişiklik gerektirmediğinden emin olmanız gerekir. Göç karmaşık bir süreçtir, ancak doğru yapılırsa eski, modası geçmiş teknolojiye yeni bir başlangıç ​​verebilir.

Mevcut sistemde DevOps'un yerinde olup olmadığını kontrol ettiğinizden emin olun. DevOps, sistem geliştirme yaşam döngüsünün kısaltılmasına yardımcı olur ve sürekli teslimat sağlar. Mevcut sistem bu araçları zaten kullanıyorsa, yükseltilmiş sürüme geçebilir veya aynı şekilde devam edebilirsiniz. Geliştiriciler için geçiş sürecini biraz kolay ve sistematik hale getirdiğinden, her zaman bir tür CI/CD araçlarının kullanılması önerilir. Ayrıca, geliştirme ekibi katı bir kod incelemesi ve kod gönderme yaklaşımı izlemelidir, örn. GitFlow modeli veya GitHubFlow.

Projenin gerekliliklerini, geçiş kapsamını ve teknoloji yığınını öğrendikten sonra, platformunuz için daha iyi bir alternatifi kolayca seçebilirsiniz. Farklı göç türleri vardır ve bununla ilerlemeden önce, her göçün aynı olmadığını ve her bir göçün uygun planlama ve yürütme gerektirdiğini açıklığa kavuşturmama izin verin. Göç ve türleri çok daha geniş konulardır, bu nedenle bu blogun devamında her bir göç hakkında ayrıntılı bilgi alabileceğiniz 3 farklı bölüm bulunmaktadır. Bir sonraki blogda, türleri ile Teknoloji Göçünden bahsedeceğiz. Öyleyse, bizi izlemeye devam edin!