Dev, QA, Release ve Live


Çağdaş dünyanın yeni fabrikaları yazılım üreticileridir. Dijital fabrikalarda, kaliteli yazılım üretmek için benimsenen Agile, DEVOPS gibi popüler metodolojiler vardır. Workcube Topluluğu kooperatifçilik anlayışıyla evrensel kabul görmüş metodolojileri de kullanarak LEAN yaklaşımını hedefleyen bir yazılım fabrikası işletmektedir.


Workcube Kodu Nasıl Geliştirilir?

  1. Workcube geliştirim süreci Git üzerinde yapılır.
  2. Atlassian Bitbucket bulutundaki ortak repository'deki Master branch'dan kodlayıcılar kendi bilgisayarlarına güncel kodu pull ederler.
  3. Kodlayıcılar onlara atanmış olan görevleri kodlar ve ilk testi yaptıktan sonra DEV branch'ına "Pull Request" ile kodu gönderirler.
  4. Kod imalat akışını takip etmek için her bir işe geçici Task-Branch açılır. Her bir iş bir "Pull Request" olmak zorundadır.
  5. Pull Request edilen kod review edilir ve kod yöneticileri tarafından "DEV" branchına Merged edilir.
  6. QA takımı "DEV" branchına Merged edilen kodu networg.workcube.com portalindeki iş kayıtları üzerinden izler.
  7. Her bir işi ve işe bağlı merged edilmiş kodu dev.workcube.com portalinde test eder.
  8. QA takım üyesi, test sonucunu kodlayıcıya geri bildirim yapar.
  9. Test sonucu başarısız ise "Revizyon" istenir.
  10. Test sonucu başarılı "Sürüm Ekle" onayı verilir.
  11. Sürüme Ekle statüsündeki iş ve ilişkili kod "Master" branchına Pull edilir.
  12. Kod Yöneticisi, kontrol gerçekleştirdikten sonra kodu "Master" branchına merged eder ve task branchını Close ederek bitmiş işe özel olarak açılmış branchı siler.
  13. QA takımı, "Master" branchına Merged edilen kodu networg.workcube.com portalindeki iş kayıtları üzerinden izler.
  14. Aynı işi ve işe bağlı merged edilmiş kodu qa.workcube.com portalinde test eder.
  15. QA takım üyesi, test sonucunu kodlayıcıya geri bildirim yapar.
  16. Test sonucu başarısız ise "Revizyon" istenir.
  17. Test sonucu başarılı ise iş detayına Release Notu eklenir.
  18. Release Notu, Hotfix ve Feature olarak ikiye ayrılarak "Sürüm Notları" altında yayınlanır.
  19. Kullanıcılar ve Sistem Yöneticileri Workcube içinden "Sürüm Notları"na erişerek upgrade yapabilir ve notları okuyabilirler.

Workcube'e Geliştirim Önerisi ve Sorunlar nasıl bildirilir?

  1. Workcube binlerce iş fonksiyonundan oluşan web sayfaları ile sunulan büyük bir web sitesidir.
  2. Workcube'de her sayfanın sağ üst köşesinde "?" işareti altında dropdown menü açılır.
  3. Bu menüdeki "Sorun Bildir" linkine tıklanarak wiki.workcube.com/addhelp ekranına gidilir.
  4. AddHelp ekranında hata veya öneri ile ilişkili sayfanın teknik bilgileri incelenmek üzere arka planda Workcube'e gönderilir.
  5. Kullanıcıdan ek olarak ekran resimleri ve loom videosu istenir.
  6. QA Karşılama Ekibi, çağrıları gruplandırır, tanımlar ve kullanıcıya geri bildirim yapar.
  7. Çağrının geldiği Workcube sürümü, güncel sürüm ve patchler ile karşılaştırılır.
  8. Güncel sürümde test case yapılır.
  9. Hata release.workcube.com'da yok ise; kullanıcıya güncel sürümde "Patch Alın" bildirimi yapılır.
  10. Hata release.workcube.com'da var ise; QA sürümü kontrol edilir.
  11. Hata qa.workcube.com'da yok ise; kullanıcıya "Versiyonla Gelecek" bildirimi yapılır.
  12. Hata qa.workcube.com'da var ise; kullanıcıya "İncelemeye Alındı" bildirimi yapılır.
  13. Hata QA takımı tarafından incelenir ve bulgular ortaya çıkarılarak DEV takımına iş açılır.
  14. DEV takımı, Workcube Proje Yönetimi ve onunla entegre çalışan Bitbucket bulutu üzerinde geliştirim sürecini yönetir.

Neden her zaman güncel sürümde olmalıyız?

  1. Geliştiriciler her zaman "Master" branchını alarak çalışmalıdır. Böylelikle en güncel sürüm üzerinde çalışmış olurlar.
  2. Müşteriler her zaman Güncel Sürüm'de olmalıdır. Böylelikle yeni özellikleri ve hotfixleri almış olurlar.

Güncel sürüme nasıl geçeriz?

  1. Sol üst köşedeki Workcube Logosu üzerine geldiğinizde Workcube 19.12 ve üstü sürüm no'sunu görmüyorsanız; Master ve daha kötüsü DEV branchından alınmış bir klon kullanıyorsunuz demektir.
  2. DEV Branchı geliştirim, QA Branchı test ortamıdır. Muhtemelen ilk kurulum yapıldıktan sonra ya upgrade olmuyorsunuz ya da manuel güncelleme yapıyorsunuzdur. 
  3. DEV ve Master branch kullanımı canlı uygulamalar için çok riskli bir durumdur.
  4. Kalite kontrolden geçmemiş ve eski kalmış bir Workcube Developer Edition canlı kullanım için kesinlikle uygun değildir.
  5. Dev ve Master branchlerde kalmış, Developer Edition'dan kurulmuş canlı kullanımlar mutlaka sürüme geçmelidir.
  6. Sürüme geçiş için yapılması gereken işlemleri anlatan wiki maddesini inceleyiniz. >> https://wiki.workcube.com/help/9773

Müşteri suncularında Canlı Ortam ve QA ortamı neden kurulmalıdır?

  1. Özelleştirme yapılan veya ek kod yazılan işletmelerde implementasyon aşamasından başlayarak aynı sunucuya qa.domain ve live.domain olmak üzere iki Workcube kurulur.
  2. "qa.domain" ve "live.domain" aynı veri tabanına bağlanan iki Workcube sitesidir.
  3. "qa.domain" her zaman en yeni sürüm ile güncellenir.
  4. Sistem yöneticileri ve kullanıcılar, "qa. domain"de,  aynı verilerle yeni gelen veya gelmesini bekledikleri özellikleri inceleyebilir, bunlar üzerinde işlemler yapabilirler.
  5. Yeni sürümde olası hatalar, veri farklılıkları ve kullanım pratikleri "live.domain"i etkilememesi için; "live.domain" bir önceki release'den veya patch'den çalışır.
  6. Sistem yöneticisi ve anahtar kullanıcılar, temel kullanım testleri yaptıktan sonra "live.domain"i yeni sürüme geçirirler.
  7. Böylelikle anahtar kullanıcılar sürüm geçişlerinde qa ortamında çalışırken standart kullanıcılar da live'da çalışır. Mission critical işler sekteye uğramaz.
  8. Live.domain'i her zaman güncel tutmak, old.domain'ini yaratarak bir önceki sürümde bırakmak seçeneği de uygulanabilir.
  9. Açık kaynak kodu kullanım hakkına sahip olanlar, buna ek olarak dev.domain'i kurabililirler.
  10. Dev.domain'i için dev veri tabanı kurularak, canlı veri tabanını yalıtılır.
  11. Dev ortamında yapılan özelleştirme ve geliştirimler müşteri qa veya live ortamına aktarılabilir. Bu yükümlülük müşteri ve iş ortaklarına aittir.

Sektörel Çözümler, eklentiler nasıl upgrade edilir?

  1. Workcube dizinininde sektörel çözümler veya eklentiler Addons/Partner_Adı/Çözüm_Paketi klasöründe yer alır.
  2. Bu klasör, ana dizinde WBP klasörü içindeki FactorySettings klasörü ile tamamen aynı klasör ve dosya yapısında olmalıdır.
  3. Addon lisanslarına sahip kurulumlarda lisans kontrolü yapılır.
  4. Addon geliştiricileri kendilerine ait klasördeki Files ve WRO dosyalarını Git üzerinde geliştirmeye devam ederler.
  5. Lisansa sahip kurulumlarda eklentiler otomatik upgrade edilir.

Yerelleştirme nasıl yapılır?

  1. İngilizce ve Türkçe arayüz, standart kütüphanede yer alır. Bunlar standart kurulumun bir parçasıdır.
  2. Dev ve QA ortamında geliştirimler yapılır ve QA takımı düzenli olarak arayüz için sözlük geliştirir.
  3. Almanca, Fransızca, Arapça, Rusça, İtalyanca ve diğer sözlükler, düzenli olarak dev ve qa ortamında olmak kaydıyla, yerel iş ortakları ile işbirliği içinde  geliştirilmektedir.
  4. Standart uygulamalardaki Kelime, Tanım ve Tümceler yerel iş ortağı tarafından düzenli olarak dev ve master branchına eklenir.
  5. Yerel kanun ve mevzuata uyum için geliştirilen eklentiler ve buna uygun olarak özelleştirilen dosyalar Addons/Partner/Ulke klasörü altına koyularak DEV ve Master branchına Git ile eklenir.
  6. Bir sayfada sözlükten gelen kelimeleri görmek için sol üst köşedeki ayarlar ikonuna tıklanır. Setting sekmesinde "Diğer" başlığı altında "Development Mode" checkboxı işaretlenir.
  7. Sayfa güncellenince sözlükten gelen kelimeler |Kelime| şeklinde görünür. Tıklandığında sözlüğe gidilir.

Kod seviyesinde özelleştirilme nasıl yapılır?

  1. Bir Workcube objesine (WO: fuseaction), 4 başlıkta dosya eklenerek extented edilebilir.
  2. DevTools'da, Workcube Objects listesinde, WO-Fuseaction bulunur. WO detayında extented inputlarına ek dosya pathleri yazılır. 
  3. Böylelikle WO-Fuseaction request edildiğinde before extented dosyaları çalışır. Kaydet veya güncelleme ile birlikte after extented dosyaları çalışır.
  4. Addoptions, standartta gelen dosya yerine özelleştirilmiş bir başka dosyanın çalışmasıdır.
  5. WO-Fuseaction altında özelleştirilmiş dosyanın pathi, Addoptions Control Path alanına yazıldığında; standart yerine addoption dosyası çalışır.
  6. Addoptions, standart sürümden uygulamayı ayırdığı için tavsiye edilmez. Gerekmedikçe kullanmayınız. 2021'de addoptions özellliği kaldırılacaktır.
  7. BPM uygulaması altında süreç-aşama ekranlarına display file veya action file eklenir.
  8. Özel raporlara dosya upload edilerek özel raporlar eklenir.
  9. Genel ayarlar altında Sistem Yazıcı Belgeleri ve Şablonlar'a özel geliştirilmiş dosyalar eklenir.
  10. Arayüzde kelime değiştirmek için yeni kelime sözlüğe eklenir. Upgrade'lerden etkilenmemesi için "Upgradelerde Etkilenmesin" checkboxı işaretlenir.

Kuruma özel geliştirdiğim kodları nerede saklamalıyım?

  1. Workcube Geliştirici Topluluğuna ait Bitbucket reposunda kuruma özel bir branch açarak saklamalısınız.
  2. Kod sürekliliği ve yedekleme için çağdaş yöntem; kurum sunucusunda kod depolamak değildir. 
  3. Hizmet alınan iş ortağı değişebilir, geliştiriciler projeden ayrılabilir ve sunucular çökebilir. Bu sebeplerle kişiye bağımlı olmamak ve riskleri azaltmak için mutlaka projenizi bir branch'de tutunuz.
  4. Kuruma özel branch Projects/ProjeAdı şeklinde repository'de açılır. Networg.workcube.com'da ilgili projenin Bitbucket adresi girilir.
  5. Kuruma özel geliştirilmiş kodların sürüm ile çalışması isteniyorsa "Master" branchı içinde Addons/Custom/ProjeAdı klasörüne konulur.
  6. Geliştiricinin Addons/Custom/ProjeAdı klasöründe yaptığı her düzenleme, sürüm geçişlerinde otomatik upgrade olur.

Geliştirimler Devtools'da hangi başlıklar altında toplanır ve kayıt edilir?

  1. WO - Workcube Objeleri - Fuseactions
  2. Widget - Bir WO'nun eventinde kullanılan boxların içini oluşturur.
  3. WEX - Web Servisleri ve REST uygulamalarıdır.
  4. Output Templates - Çıktı Şablonlarıdır.
  5. Process Templates - Display ve Action File dosyalarıdır.
  6. Extensions - Bir WO'yu genişletmek için kullanılır.

KVKK Kurallarına göre bilgi alışverişi nasıl yapılır?

  1. Workcube abonesi olan kullanıcı şirketlerin yetkilendirilmiş çalışanları ve yetkili iş ortakları Çağrı Merkezine bildirimde bulunabilir.
  2. Sistem-Erişim-KVKK-İletişim Dokümanı doldurularak yetkili kişiler register edilmelidir.
  3. Her bir Workcube kurulumunda Genel Ayarlar > Uygulama Bilgileri ekranındaki bilgilerin doldurulması zorunludur.
  4. Bu kurallara uymadan yapılan bildirimlere KVKK kuralları gereği bilgi verilmez.

Geri Bildirim

Bu içeriği faydalı buldunuz mu?
İlişkili İçerikler