Akaunting 3 yükseltme: 2.x'ten 3.x'e veri kaybetmeden geçiş planı

Akaunting 2.x'ten 3.x'e yükseltme, bir güncelleme düğmesinden çok küçük bir taşıma projesidir: 3.x, PHP 8.1 veya üstünü istiyor, 2.x ise PHP 7.4 üzerinde çalışıyordu. Güvenli yol; kurulu uygulamaların ve özelleştirmelerin envanterini çıkarmak, geçişi önce bir kopya ortamda yapmak, rapor toplamlarını geçiş öncesi ve sonrası karşılaştırmak ve canlı geçişe provası yapılmış bir geri alma planıyla girmektir. Aşağıda bu planı adım adım anlatıyoruz.

Neden 2.x'te kalmak giderek pahalılaşıyor?

2.x kurulumu bugün sorunsuz çalışıyor olabilir. Sorun bugünde değil, altındaki katmanlarda.

• PHP 7.4 artık güvenlik yaması almıyor. PHP projesinin bu sürüme desteği sona erdi. Sunucunuzda yeni bir açık bulunduğunda bunun düzeltmesi gelmeyecek.
• Laravel tarafı da aynı durumda. 2.x'in üzerine kurulduğu Laravel sürümü, Laravel'in destek politikasına göre güvenlik düzeltmesi alma süresini çoktan doldurdu.
• Hosting firmaları eski PHP'yi kaldırıyor. Paylaşımlı hostinglerde PHP 7.4 seçeneğinin bir gün panelden kaybolması, 2.x kurulumunu planlanmamış bir anda çalışmaz hale getirebilir.
• Uygulamalar ve düzeltmeler 3.x'e gidiyor. Yeni özellikler, hata düzeltmeleri ve App Store uygulamalarının güncel sürümleri 3.x serisi için yayımlanıyor. 3.x içinde bile, örneğin gelir tablosunda bir gideri iki kez sayan bir hata 3.2.1 sürümünde düzeltildi; eski bir sürümde kalan kurulum, bu tür düzeltmelerin hiçbirini almıyor.

Kısacası soru "yükseltmeli miyiz" değil, "planlı mı yoksa zorunda kalınca mı yükselteceğiz" oluyor. Planlı geçiş her zaman daha ucuz.

3.x ile neler değişiyor?

Geçişi planlarken üç değişikliği ayrı ayrı ele almak gerekiyor:

Sunucu. PHP 8.1 veya üstü, buna uygun eklentiler ve komut satırında da aynı PHP sürümü. Çoğu durumda bu, mevcut sunucuyu yükseltmek yerine yeni bir sunucu hazırlamak anlamına geliyor. Bu aslında iyi bir fırsat: yeni sunucuyu baştan doğru kurarsınız, eskisi de geri dönüş noktası olarak yerinde kalır.

Arayüz ve görünüm katmanı. 3.x ile arayüz büyük ölçüde yenilendi. Çekirdek şablon dosyalarına elle yapılmış her değişiklik ve ekranlara müdahale eden her modül, yeniden ele alınmalı. 2.x'te bir Blade dosyasını düzenleyerek yapılmış bir fatura şablonu değişikliği, 3.x'e olduğu gibi taşınamaz.

Uygulamalar. Her App Store uygulamasının 3.x ile uyumlu bir sürümüne ihtiyacınız var. Akaunting'in sürüm politikasında uygulamalar çekirdek sürümüyle birlikte ilerliyor ve modül geliştiricilerinin eski çekirdeklerle geriye dönük uyumluluk tutması beklenmiyor. Yani 2.x için alınmış bir uygulamanın 3.x sürümü yoksa, o uygulamanın işlevi geçişte ya başka bir uygulamayla ya da özel bir modülle karşılanmalı.

Geçişten önce: envanter

Geçişin başarısı, en çok bu aşamada belirleniyor. Şu soruların yazılı cevabı olmadan bir sonraki adıma geçmeyin:

• Şu an tam olarak hangi 2.x sürümündesiniz?
• Hangi App Store uygulamaları kurulu ve hangi sürümlerde?
• Her uygulamanın 3.x uyumlu sürümü var mı, lisansınız bu sürümü kapsıyor mu?
• Çekirdek dosyalarda elle yapılmış bir değişiklik var mı? (Temiz bir 2.x paketiyle dosya karşılaştırması yapmak en güvenilir yöntem.)
• Özel modül var mı, kim yazdı ve kaynak kodu nerede?
• Kaç şirket, kaç kullanıcı, yaklaşık kaç fatura var? Lisans katmanınız 3.x'te bu sayıları karşılıyor mu?
• storage klasörü ne kadar büyük, eklerin tamamı orada mı?
• Hangi başka sistemler Akaunting'le konuşuyor (API, içe aktarım, raporlama)?

Envanter sonunda iki yoldan birini seçersiniz. Yerinde yükseltme: veriyi yeni sunucuya taşıyıp 3.x'e yükseltmek. Çekirdeğe dokunulmamış, uygulamaları 3.x'te mevcut olan kurulumlar için genellikle doğru yol. Temiz kurulum ve veri göçü: 3.x'i sıfırdan kurup veriyi aktarmak. Çekirdeği yoğun biçimde değiştirilmiş ya da veritabanında elle müdahale izleri olan kurulumlarda daha güvenli olabilir.

Adım adım geçiş planı

1. Tam yedek ve geri yükleme provası. Veritabanı, storage, modules ve .env dahil uygulama klasörünün tamamı. Bu yedeği ayrı bir ortama geri yükleyip açabildiğinizi görmeden ilerlemeyin.
2. "Önce" ölçümlerini alın. Aşağıdaki doğrulama tablosundaki her değeri, 2.x'te, belirli bir tarih için not edin ya da rapor olarak dışa aktarın.
3. 2.x'i serinin son sürümüne getirin. 3.x'e geçişin hangi 2.x sürümünden desteklendiğini sürüm notlarından doğrulayın; genellikle önce mevcut serinin en güncel sürümüne çıkmak gerekiyor. Bunu da önce kopyada yapın.
4. Yeni sunucuyu hazırlayın. PHP 8.1 veya üstü, eklentiler, CLI PHP, cron, SMTP, HTTPS.
5. Kopya ortamda geçişi yapın. Veriyi yeni sunucuya alın, çekirdeği 3.x'e yükseltin, ardından her uygulamayı 3.x uyumlu sürümüne getirin. Her adımın çıktısını saklayın; bir hata olursa nerede olduğunu bilmek isteyeceksiniz.
6. "Sonra" ölçümlerini alın ve karşılaştırın. Fark çıkan her kalemi ya açıklayın ya düzeltin.
7. Kullanıcı kabulü. Faturayı en çok kesen kişi ve mali müşaviriniz kopya ortamda günlük işlerini bir kez yapsın.
8. Canlı geçiş penceresi. Provada ölçtüğünüz sürenin rahatça sığdığı, ay sonuna denk gelmeyen bir zaman seçin. Pencere başında 2.x'e yeni kayıt girişini durdurun, son yedeği alın ve kopyada çalışan diziyi aynen tekrarlayın.
9. Geçiş sonrası izleme. İlk hafta günlükleri, cron'u ve e-posta gönderimini takip edin.

Veriyi doğrulamak: neyi, nasıl karşılaştırmalı?

"Ekranlar açılıyor" doğrulama değildir. Aynı tarih aralığı için geçiş öncesi ve sonrası şu değerleri yan yana koyun:

Bir uyarı: Rapor toplamlarında çıkan her fark veri kaybı anlamına gelmiyor. 2.x'te bir hatadan dolayı yanlış hesaplanan bir rapor, 3.x'te doğru hesaplanıyor olabilir. Bu yüzden fark çıkan kalemi kayıt düzeyine inerek açıklamak gerekiyor; "yaklaşık tutuyor" kabul edilebilir bir sonuç değil. Mali müşavirinizin bu tabloyu görmesi, hem doğrulama hem kayıt açısından değerli.

Geçişlerde sık yapılan hatalar

Planı yazmak kadar, nerede ters gidebileceğini bilmek de önemli. En sık karşılaşılan hatalar:

• Geçişi güncelleme gibi ele almak. 2.x üzerinde güncelleme düğmesine basıp 3.x beklemek, çoğu zaman yarım kalmış bir kurulumla sonuçlanır. Sunucu değişikliği ayrı bir adım olarak planlanmalı.
• Yedekte storage klasörünü unutmak. Veritabanı taşınır, kayıtlar görünür, ama fatura ekleri açılmaz. Bu, geçişten haftalar sonra fark edilebilir.
• Uygulamaları sonra düşünmek. Çekirdek 3.x'e geçtikten sonra bir uygulamanın uyumlu sürümü olmadığını öğrenmek, geri dönmek ya da o işlevi aceleyle başka yoldan karşılamak zorunda bırakır.
• Entegrasyonları test etmemek. Akaunting'e veri gönderen ya da ondan veri okuyan başka bir sistem varsa, API davranışı değişmiş olabilir. Bu bağlantılar da kopya ortamda denenmeli.
• Kullanıcıları dahil etmemek. Yeni arayüzü ilk kez canlı geçiş sabahı gören bir ekip, ilk hafta beklenenden yavaş çalışır.

Geri alma planı ve kesinti penceresi

Geri alma planı, geçiş günü değil, geçişten önce yazılır. İçinde şunlar olmalı:

• Geri dönüş noktası: canlı geçiş başlamadan alınan son yedek ve eski 2.x sunucusunun dokunulmadan beklemesi.
• Karar kriteri: hangi durumda geri dönüleceği önceden belli olmalı. Örneğin doğrulama tablosunda açıklanamayan bir fark ya da pencerenin belirli bir saatini aşan bir gecikme.
• Geri dönüş adımları: alan adını ya da yönlendirmeyi eski sunucuya çevirmek ve kullanıcılara haber vermek. Bu adımları kopya ortamda bir kez deneyin.
• İletişim: kullanıcılara pencereyi önceden duyurun; pencere boyunca kayıt girmemelerini isteyin.

Eski sunucuyu geçişten hemen sonra kapatmayın. Birkaç hafta salt okunur olarak beklemesi, "geçen yılın şu faturası nasıl görünüyordu" sorusuna cevap vermenin en kolay yolu.

Nereden başlamalı?

İlk adım envanter. Hangi sürümde olduğunuzu, hangi uygulamaların kurulu olduğunu ve çekirdeğe dokunulup dokunulmadığını yazılı hale getirdiğinizde, geçişin büyüklüğü de netleşir. Önceden yarım kalmış bir güncelleme denemesi varsa, önce onu ele almak gerekir; Akaunting güncelleme hatası yazımız bu durum için güvenli bir sıra veriyor. Çekirdek dosyalarda yapılmış özelleştirmeler varsa, onları 3.x'e taşırken güncellemeden etkilenmeyen bir modüle dönüştürmek, bir sonraki yükseltmeyi de kolaylaştırır.

Bu işi birlikte yapmak isterseniz, Akaunting sürüm yükseltme ve kurtarma hizmetimizde 2.x'ten 3.x'e geçişi önce bir tespitle kapsamlıyor, ardından kopya ortamda prova edip sizin seçtiğiniz pencerede canlıya alıyoruz. Durumunuzu iletişim sayfamızdan kısaca yazmanız yeterli.