Atlassian açık betası Jira yapılandırma değişikliklerini sandbox'tan production'a deploy ediyor

Atlassian, yöneticilerin Jira ve Jira Service Management yapılandırma değişikliklerini üçüncü taraf bir uygulama olmadan doğrudan sandbox'tan production'a göndermesini sağlayan bir beta açtı. Şirketin sandbox'lardan sorumlu ürün yöneticisi, açık betayı 6 Temmuz 2026 tarihli bir Atlassian Community gönderisinde duyurdu — 14 Kasım'a kadar 8.965 görüntüleme aldı — ve dev.to'da yayımlanan uygulamalı bir yazı, aracın pratikte ne yaptığını ve nerede takıldığını gösteriyor.

Beta neleri kapsıyor

Atlassian'ın dokümantasyonuna ve dev.to'daki özetine göre bir deployment, workflow'ları, alanları, ekranları, şemaları, panoları, filtreleri ve otomasyon kurallarını production'a taşıyabiliyor. Özelliğin kısıtlamaları var. Deployment'ı yalnızca organizasyon yöneticileri çalıştırabiliyor; site yöneticileri çalıştıramıyor, ancak açık bir feature request (CLOUD-13068) Atlassian'tan bunun değiştirilmesini istiyor. Premium veya Enterprise planında Jira veya Jira Service Management gerektiriyor — Premium'da uygulama başına bir sandbox, Enterprise'ta en fazla beş — ve yalnızca normal bulutta çalışıyor, Atlassian Government Cloud'da değil. Team-managed projeler desteklenmiyor. Deployment'lar ayrıca kesinlikle tek yönlü: inceleme ekranı, deploy edilen değişikliklerin "geri alınamayacağı" konusunda uyarıyor.

Deploy düğmesinden önce duran bir test

14 Kasım'da dev.to yazarı betayı kendi organizasyonunda, Premium planıyla test etti ve herhangi bir şey onaylamadan önce inceleme ekranında bilerek durdu. Sandbox'ları production verilerinin bir kopyasını hiç almamıştı ve ilk tarama bunu gösterdi: yaklaşık 13 dakikalık tarama 764 fark ortaya çıkardı; bunların 752'si ekleme, 12'si değişiklikti.

Test değişiklikleri company-managed bir projedeydi — yeni bir workflow durumu, bir validator, özel bir açılır liste alanı, bir ekran, paylaşımlı bir filtre, bir proje rolü ve bir otomasyon kuralı — her biri aranabilir bir önek ile adlandırılmıştı. Bu değişikliklerden sonraki yeniden tarama 5,4 dakika sürdü, fark sayısını 785'e çıkardı ve 19 eşleşen öğe ortaya çıkardı.

Dört öğeyi (proje, filtre, proje rolü ve otomasyon kuralı) işaretlemek, otomatik seçilen bağımlılıkları da içine katarak seçimi 16'ya çıkardı; validation ise seçimi 110'a genişletti — çoğunlukla projenin alan şemasının dayandığı alanlar. Bunlardan on ikisi başarısız oldu, proje de aralarındaydı; dolayısıyla yazarın göndermek istediği tek şey gidemedi. Uyarılardan biri, her iki sitede de var olan Story Points alanıyla ilgiliydi ve ekranın önerdiği çözüm — production'ın sandbox'a tam kopyasını almak — içinde zaten olan her şeyin üzerine yazacaktı. Hiçbir deployment çalıştırılmadı ve production sonradan dokunulmamış kaldı.

Yeni kopyalar, çelişen tarihler

Atlassian, deployment'ların yalnızca sandbox elinde production'ın güncel bir tam kopyası varken doğru olduğunu belirtiyor. Tarama bir kopya olmadan da çalışıyor, ancak hiç kopyalanmamış bir sandbox neredeyse her şeyi yeni gösteriyor ve aynı adlı alanları yinelenen öğe uyarılarına dönüştürüyor. dev.to yazarı, sandbox'taki demo verilerini korumak için kopyalamayı atladı ve bu seçimin validation hatalarını açıkladığından şüpheleniyor.

Kesim tarihleri de tutarsız. Deployment bandı, Jira yapılandırmaları için (otomasyonlar hariç) 7 Şubat 2026 veya sonrasında yapılmış bir kopya, Jira Service Management yapılandırmaları ve otomasyon kuralları için ise 17 Mayıs 2026 tarihli bir kopya istedi. Atlassian'ın önerilen workflow sayfası ise ikinci tarih için 7 Mayıs veriyor; dolayısıyla 7 ile 17 Mayıs arasına tarihlenen kopyalar dokümantasyonu karşılıyor ama ekranı karşılamıyor. Tam kopya ayrıca aynı Jira ailesi sandbox'ına bağlı Jira Service Management ve Product Discovery sandbox'larının üzerine yazıyor.

Workflow'un kendisi yedi aşamadan oluşuyor: sandbox'ın son yenileme zamanını kontrol et, değişiklikleri yap, deployment'ı oluştur ve production sitesini seç, tarama sonuçlarında ara, öğeleri seç ve aracın otomatik eklediklerini incele, yan paneldeki her hatayı gözden geçir, sonra deploy et ve raporu oku.

Neden önemli

Sandbox'tan production'a giden yerleşik bir yol, Jira yöneticilerine yapılandırma çalışması için gerçek bir staging adımı sunuyor — bir workflow'u veya otomasyon kuralını kullanıcılardan uzakta test et, sonra yükselt — production'ı doğrudan düzenlemek veya değişiklikleri elle tekrarlamak yerine. dev.to testi, araçların bunu ciddiye aldığını gösteriyor: bağımlılıklar otomatik olarak içine katılıyor ve hatalar, herhangi bir şey yerleşmeden deploy'u engelliyor. Ama kısıtlamalar gerçek. Deployment'lar geri alınamaz, Premium veya Enterprise planlarındaki organizasyon yöneticileriyle sınırlı, team-managed projeleri dışarıda bırakıyor ve sandbox elinde production'ın güncel bir kopyası yoksa gürültüye dönüşüyor. Betayı benimseyen ekipler, sandbox yenilemelerini deployment rutininin bir parçası olarak görmeli, sonradan akla gelen bir ayrıntı olarak değil.