Open edX’i 4 Sürüm Birden Güncellemek

Open edX ile çalışmaya başlamam 2021 yılının son aylarına tekabül ediyor. Yeni test ve canlı ortam kurulumları, mevcut kurulumların bakım ve geliştirme işleriyle uzun süredir ilgileniyorum. Dolayısıyla, Artistanbul’da Open edX’in teknik altyapısından sorumlu olarak rol alıyorum. Her gün Open edX hakkında yeni bir teknik detay öğreniyoruz. Bu yazılımı tam olarak anlamanın pek de mümkün olmadığına epey önce ikna oldum diyebilirim. Open edX süreçlerini devraldıktan sonra bugüne kadar en çok zorlandığım iş, test ve canlı ortamda 4 sürüm birden güncelleme yapmak oldu.

Sürüm güncelleme öncesindeki hazırlık aşamaları

Artistanbul’da kazandığım en önemli alışkanlıklardan bir tanesi; işe başlamadan önce kendim için bir yapılacak listesi hazırlamak. İlk akla gelen işlerle başlayan ve yavaş yavaş tüm detayların sırasıyla yazıldığı bir listeye evriliyor. Operasyonel işlerde herhangi bir adımın atlanmaması gerekiyor. Şirket prosedürlerinin belirlenmesi için yapılacaklar listesinin de oldukça önemli olduğuna inanıyorum.

Bir Open edX güncellemesi için hazırlık aşamasında mevcut sürüm bilgisi, izlenecek sürüm yolu, her yeni sürüm kurulumu öncesi ve sonrası yapılması gereken ek değişiklikler ve veritabanı göç detayları öncelikli olarak incelenmeli. Bu adımda en önemli nokta, yapılması gereken ek değişiklikler olarak karşımıza çıkıyor.

Örneğin, bir Open edX kurulumunda LMS ve Studio yazılımlarının kullandığı Docker imajları derlenirken ek tema geliştirmeleri de derlenir. Sürüm güncelleme işlemleri sırasında bir ara sürümün temanızla uyumlu olup olmaması önceliğiniz olmamalıdır. Dolayısıyla ek tema geliştirmelerini son imaj derleme adımına kadar derlemeye dahil etmeyebilirsiniz. Böylece uzun bir Dockerfile’dan oluşan Open edX imajını derlerken zaman kazanabilirsiniz.

Ek olarak, Open edX kurulumu için ortama özel olarak kullanılan SMTP, veritabanı bilgileri, alan adı ve ihtiyaca göre açılıp kapatılan Open edX özellik anahtarları gibi ayarlar kontrol edilmeli. Bu ayarlarda olabilecek bir uyumsuzluk testlerde hataların oluşmasına, yanlış yönde ilerlemeye sebep olabilir. Sonuç olarak kişisel tercihim, tüm detayların yer aldığı yedekler almak ve izlenecek yol haritasını açıkça belirlemek.

Bu hazırlık aşaması görece uzun zaman alıyor gibi görünebilir. Open edX gibi karmaşık bir yazılımı güncellerken bir sorunla karşılaşmamayı da hazırlık “zahmetine” katlanmaya borçluyuz.

Sürüm güncelleme sırasında veritabanı göçü

Güncellemeler sırasında beni en çok düşündüren konu, 4 büyük sürümün birbirleri arasındaki veritabanı farkları oldu.

Bilindiği üzere Open edX, Micro Frontend altyapısına geçişte önemli bir yol katetti. Koa sürümünde Django ile sunulan birçok kod bloğu önyüzde kullanılmıyor. API, her biri ayrı kod depolarından oluşan MFE uygulamalarına veri sunmakla sorumlu. Dolayısıyla herhangi bir veri yapısı değiştiğinde tamamen uyumlu çalışması için epey dikkatli davranmak gerekiyor.

Veritabanı göçü komutları çalıştırılmadan önce her adımda kesinlikle yedek alınması ve bu yedeklerin sürüm güncellemesi tamamlanana kadar saklanması, en büyük önceliğimiz oldu. Herhangi bir veritabanı hatasıyla karşılaşmasak da felaket senaryolarında veri kaybı yaşamamak için yedek almak zorundayız.

Open edX Docker imajları

Sürüm güncellemesi işi sırasında vaktin büyük bir kısmı Docker imajlarının derlenmesini beklerken geçiyor. İşin matematiği şöyle: 4 büyük sürüm güncellemesi içinde yaklaşık 12 küçük sürüm bulunuyor. Open edX ve MFE imajları için ayrı ayrı imaj derlemek gerekiyor. Bir başka deyişle, toplamda 24 kez imaj derleniyor. Dockerfile neredeyse büyük ölçüde değişeceği için “cache” özelliği neredeyse hiçbir noktada işe yaramıyor. Dolayısıyla 24 kez imaj derlemek için toplamda 3 saat beklemek gerekebiliyor.

Artistanbul’da müşterilerimizin ihtiyaçlarına bağlı olarak çeşitli yöntemlerle derleme sürelerini büyük ölçüde azalttık ancak sürüm güncellemesi sırasında ne yazık ki tüm bu değişiklikleri son adımda tekrar aktifleştirebiliyoruz.

Son kontroller ve işin teslimi

4 büyük sürüm güncellemesinin test ortamında tamamlanmasının ardından ilk aşamada herhangi bir veri kaybının olmadığı benim tarafımdan teyit ediliyor. Böylece, Artistanbul ve müşteri test süreçlerimiz başlıyor. Test onay sürecimizde detaylı olarak tüm sistem kontrolleri yapılıyor. Test ortamında yapılan güncellemeler birebir olarak canlı ortamda da yapılarak tüm süreç tamamlanmış oluyor.

İşi teslim ederken kullanıcıların hak kazandığı sertifikalar, kurs tamamlama oranları ve kurs içeriklerinin uyumluluğu öncelikli olarak kontrol ediliyor. Böylece tüm sistemin işlevsel olduğu kontrol edildiğinde işi teslim etmeye hazır oluyoruz.

Sonuçta, Artistanbul’da tamamladığım en uzun soluklu ve zorlu iş olan sürüm güncelleme sırasında herhangi bir aksilikle karşılaşmadığımız için çok mutluyum.