Jira Turing tamdır

 (seriot.ch)
2 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Jira Automation, iki sonsuz sayaç ve sonlu komut durumuna sahip bir Minsky makinesini ifade edebilir; bu da Jira'nın Turing tamlığını göstermek için kullanılabilir
  • Epic durumu program sayacı, bağlı Bug ve Task sayıları iki register olur; Automation kuralları da komut başına dispatch table işlevi görür
  • INC ve DEC, bağlı issue oluşturma ve silmeyle gerçekleştirilir; koşullu dallanma ise JQL koşul kuralları ile bağlı issue sayısının kontrol edilmesiyle belirlenir
  • Toplama örneğinde A=2, B=3 iken Bug azaltılıp Task artırılır ve gerçek bir *.atlassian.net çalıştırmasında 5 Task ile durma durumuna ulaşılır
  • Fibonacci örneği, issue type dönüşümüyle döngüleri azaltır; Jira Cloud'un 10 zincir derinliği sınırına ulaşıldığında elle yeniden tetiklenerek çalışmaya devam edebilir

Jira Automation ile kurulmuş Minsky makinesi

  • Jira Automation, iki sonsuz sayaç ve sonlu komut durumuna sahip bir Minsky register machine ifade edebilir; bu sayede Jira'nın Turing tamlığını gösteren bir indirgeme yapılabilir
  • Minsky'nin 1967'de kanıtladığı model yalnızca INC r; goto S ve if r == 0 goto S else (DEC r; goto S') komutlarından oluşur
  • Jira bileşenleri, Minsky makinesinin her öğesine karşılık gelir
    • Register A: bağlı Bug issue sayısı
    • Register B: bağlı Task issue sayısı
    • Program Counter: tek bir Epic issue'nun durumu
    • Dispatch Table: komut durumuna göre Jira Automation kuralları
    • Clock: otomasyonun tetiklediği geçişler veya zincir sınırından sonra dış yeniden tetikleme
  • Epic durumu mevcut komutu kodlar ve Automation rules, bağlı issue sayılarını kontrol ederek bir sonraki duruma geçer
  • INC ve DEC, ilgili türde bağlı issue oluşturma ve silmeyle uygulanır; koşullu dallanma ise JQL koşul kuralları ile işlenir

Çalışma örnekleri ve sınırlamalar

  • Toplama programı, Ayı azaltırken Byi artıran bir Minsky programı olarak kurulur 
    1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
  • En küçük uygulama, bir Epic, 5 bağlı issue ve komut durumu başına bir Automation kuralından oluşur

  • Workflow ve kurallar

    • Jira Workflow içinde başlangıç durumu BACKLOG, ardından TODO, DEV, PROD oluşturulur ve tüm durumların birbirine geçiş yapabilmesi sağlanır
    • BACKLOG durumunda bir Epic oluşturulur
    • TODO kuralı, DEC A; if A=0 halt, else goto DEV komutunu uygular
      • Epic durumu TODO olarak değiştiğinde tetiklenir
      • En az bir bağlı Bug varsa bir Bug silinir ve Epic DEV durumuna geçirilir
      • Bug yoksa Epic PROD durumuna geçirilerek durdurulur
    • DEV kuralı, INC B; goto TODO komutunu uygular
      • Epic durumu DEV olarak değiştiğinde tetiklenir
      • Yeni bir Task oluşturulur ve Epic'e bağlanır
      • Epic TODO durumuna geçirilir
    • Her iki kuralda da "Allow rule to trigger other rules" etkinleştirilir

  • Başlangıç değerleri ve sonuç

    • Epic'e 2 Bug ve 3 Task bağlanarak A=2, B=3 olarak başlatılır
    • Epic TODO durumuna geçirildiğinde şu akış zincirleme çalışır 
      (2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
    • Bu yapı gerçek bir *.atlassian.net instance'ında çalıştırıldı ve sonunda Epic PROD durumuna ulaşıp 0 Bug ve 5 Task ile bağlandı
    • Bu çalıştırma, Jira otomasyonu ile 2 + 3 = 5 hesaplamasının sonucu oldu

  • Fibonacci yapısı

    • Convert Issue Type, Bug → Story ve Story → Task gibi issue type'ları anında değiştirebilir
    • CONVERT, DEC + INC olarak ifade edilebilir; bu hesaplama gücünü artırmaz ama taşıma döngülerinin dispatch table'ını küçülterek daha karmaşık programları işlemeyi kolaylaştırır
    • Fibonacci, (A, B) → (B, A+B) olarak ifade edilir ve üç register A=Bug, B=Task, C=Story ile üç durum TODO, QA, DEV üzerinden kurulur 
      TODO:
    if any linked Task exists:
        CONVERT Task → Story
        INC Bug
        transition to TODO
    else:
        transition to QA

QA:
    if any linked Bug exists:
        CONVERT Bug → Task
        transition to QA
    else:
        transition to DEV

DEV:
    if any linked Story exists:
        CONVERT Story → Bug
        transition to DEV
    else:
        transition to TODO
    • Başlangıç durumu A=1, B=1, C=0 olur ve Task sayısı olan B üzerinde 1, 1, 2, 3, 5, 8, 13, ... dizisi ortaya çıkar
    • Toplama makinesinden farklı olarak Fibonacci makinesinde durma durumu yoktur ve Jira Cloud'un 10 zincir derinliği sınırına ulaşana kadar çalışır
    • Sınıra ulaşıldığında operatör Epic'i yeniden tetikleyerek devam ettirebilir ve tek bir durum düzenlemesiyle zincirleme yürütme yeniden başlar
    • Jira Data Center, automation.rule.execution.timeout ve ilgili ayarları yapılandırılabilir özellikler olarak sunar
    • Sonsuz issue oluşturma ve kural çalıştırma varsayıldığında, Jira otomasyon dili iki sayaçlı makineyi kodlayabilir; fiziksel bilgisayarların da sonlu olduğu yönündeki yaygın ölçüte göre Jira Cloud'un sonlu kotaları bu yapıyı geçersiz kılmaz

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Jira tamamen korkunç; başka her türlü korkunçluğa dönüşme potansiyeline sahip

    • Jira, yabancılaşma kavramının nihai örneği
      Marx, Atlassian'ı bilseydi Grundrisse alev alırdı
    • En kötüsü, görev yönetimi ürünü yapan şirketlerin sonunda hep Jira yönüne gitmesi
      2014'teki GitHub Issues ile bugünkü halini karşılaştırmak yeterli: https://github.com/features/issues
      ve durmadan, durmadan yinelenen özellikler ekliyorlar

  • Jira çok popüler ve tercih ettiğiniz dil için API wrapper'ları da gayet iyi
    Hacker ruhuna sahip kurumsal geliştiricilerin Python komut satırı betikleri gibi şeylerle Jira'nın istediği işlerin çoğunu otomatikleştirmemiş olmasına şaşırıyorum
    Onu dayatan insanlardan en az bir mertebe daha kolay kullanabildiğim anda oyun tersine dönüyor; Jira, kendini korumak için itilen bir araca dönüşüyor
    Bazen Jira'yı neredeyse kötü niyetli şekilde kullandım; sorumluluktan kaçmak için mükemmel
    Bir sorun çıkınca “Bu, yazdığım yüzlerce Jira güncellemesinde açıkça vardı; okuyordunuz değil mi?” demek yetiyor
    Artık AI da var; her şeyi özel betiklerle birbirine bağlayıp AI'nın Jira angaryasını yapmasını sağlayabilirsiniz

    • Oldukça fazla kişi bunu zaten yaptı, ama sorun şu ki her Jira instance'ı; eski, başarısız migration'ların ve yeni organizasyon stratejilerinin katman katman biriktiği özel alanlardan oluşan fraktal bir kar tanesi
      API'nin UI'nin izin vermediği şeyleri yapabildiği çok oluyor ve herkes UI'ya göre hareket ettiği için garip kırık köşelere düşüyorsunuz
      Örneğin, custom_field_5537'nin başka birinin dashboard'unda görünmesi için custom_field_442 ile eşleşmesi gerektiğini fark etmeyebilirsiniz
      Bir de custom_field_10995 kendisinin integer alanı olduğunu iddia edip XML'de de integer olarak dönüyor, ama iş oluştururken belgelenmemiş sihirli bir sabit string kullanmanız gerekiyor; güncellerken ise buna gerek kalmıyor
      Web UI bunu böyle yapmıyor; HTML ve isteklerde sadece integer var ve stringlerin yalnızca %80'i dropdown gösterim metniyle eşleşiyor
      Jira otomasyonu yaşadığım en kötü programlama deneyimiydi
      Daha basit kurulumlar kesinlikle vardır ve oldukça kolay da olabilir, ama yine de aşırı
      Üzücü biçimde, harcanan emek hâlâ tamamen buna değiyor. Şiddetle tavsiye ederim
    • Eskiden çalıştığım yerde API ile zaman kazandıran birkaç araç yaptık ve hepsi küçük shell script'lerdi
      Her bilete, insanların okuyabileceği açıklamalar için özel bir metin alanı ekledik; bir sürüm dağıtıma çıktığında deployment script'i zaman damgasını otomatik dolduruyordu
      İş birimi başına bir bilet olacak şekilde sürüm çıkarıyorduk ve günde birden fazla bilet işliyorduk
      Özel filtrelerle birleşince Jira, her board ve şirket geneli için insanların okuyabileceği değişiklik kayıtları sağlıyordu; bu mesajlar Slack üzerinden iş tarafına iletiliyor, böylece herkes neyin dağıtıma çıktığını biliyordu
      Aynı zamanda kod değişikliklerine bağlanan, aranabilir bir sürüm denetim kaydıydı
      Deployment süreci Jira bilet durumlarını da geçiriyordu; geliştirici yalnızca bileti main'e merge ediyor, geri kalanı dağıtılıyor ve Jira'da da tamamlanmış oluyordu
      Tekrarlayan işler için biletleri otomatik oluşturan küçük script'ler de çoktu
      Yıllarca son derece sağlam kaldı ve büyük ihtimalle bugün hâlâ çalışıyordur
      Özel alan adlandırma kuralı pek iyi değildi ama ekip Jira ayarlarını kontrol ediyorsa herkesin aynı standardı koruması zor değildi
      Başta Jira'yı sevmiyordum ve uzun zaman önce çok sorunu vardı, ama bugünlerde düzgün yapılandırılırsa o kadar da kötü değil
      Kendi şirketim olsa seçmezdim ama onu geliştirici, yönetici, son kullanıcı ve iç araç geliştiricisi olarak kullanmış biri olarak, bir kez kurulup çalışmaya başladığında çoğu zaman engel olmuyor
    • “Her şeyi özel betiklerle birbirine bağlayıp AI'nın Jira angaryasını yapmasını sağlamak”, sanki Jira'nın şişkinliği zaten yeterli değilmiş gibi geliyor
      Daha fazla metin eklerseniz Jira somehow her şeyin üstünde sürekli her şeyi otomatik çalıştıracağı için daha da yavaşlayacak
      Şirketinizin ısınmaya ihtiyacı varsa Jira kullanın
    • Çok uzun zaman önce JetBrains YouTrack'a geçtik ve API'siyle bu tür şeyler yaptık
      Oldukça esnek ve AI sayesinde daha da açıldı
    • Bizim tüm şirket fiilen Jira üzerinde çalışıyor
      Süreçlerin çoğu Jira'ya bağlı ve belirli geçişler otomasyon için webhook'ları tetikliyor
      AI erişimi alır almaz yaptığım ilk işlerden biri Jira MCP yapmak oldu
      Artık Jira'ya neredeyse hiç doğrudan dokunmamaya çalışıyorum; Claude'a Jira issue oluşturma, yorum yazma, alt görev oluşturma, issue bağlama gibi işleri yaptırıyorum
      Eskiden bir şeyin nasıl uygulanacağını araştırıp onu görevlere bölmek gerektiğinde korkardım
      Çünkü ne kadar ayrıntılı bölerseniz, bunları koymak için o kadar çok Jira issue'su oluşturmanız gerekiyordu
      Şimdi ise her şeyi bir dosyada düzenleyip büyük dil modeline Jira angaryasını bırakabiliyorum

  • Eskiden çalıştığım yere geri döndüm, hâlâ JIRA kullanıyorlardı
    Mülakatta tabii ki “Aa JIRA mı, hâlâ onu mu kullanıyorsunuz? Kullanırım tabii” dedim
    Gerçekten kullanabiliyorum ama en güncel JIRA’yı görünce sahiden şoke oldum
    Bin tane küçük rahatsızlık var ve en kötülerinden biri, metni seçmek için çift tıklamaya çalıştığınız anda alanın birden düzenleme moduna geçmesi
    Benim hatırladığım sürüm JIRA Server 4.0’dı; nostalji yapmak isteyenler şuradan bakabilir: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
    Yeterince yakınlaştırınca her issue’da başlık, tür, fix version, affects version gibi bilgiler vardı ve yapı doğrudan yorumlara bağlanıyordu. Çok basitti

    • Çift tıklamanın düzenleme moduna sokması olayı gerçekten doğru
      Aşırı sinir bozucu. En temel metin işlemleri bile yanlış
      Ama bunu sevdiğini söyleyen bir proje yöneticisi olmuştu
      Çünkü bir kelimenin tamamını seçmek için çift tıklayıp sürüklemeyi kullanmıyormuş
      Her zamanki gibi, bilgisayarı zar zor kullanabilen insanların rahatlığı yüzünden daha yetkin kullanıcılar aşağı çekiliyor
    • “JIRA mı, hâlâ onu mu kullanıyorsunuz?” tepkisi bana tuhaf geliyor
      Bir şeyi mi kaçırdım, zaman boşluğuna mı düştüm diye düşündürüyor
      Neden Jira’dan Visicalc’mış gibi bahsedildiğini anlamıyorum
      Şu an bir BT şirketinde çalışmıyorum, o yüzden son 2 yılda yaşanan büyük bir dönüşümü kaçırmış olabilirim
    • Hisse fiyatı ile ürüne yönelik olumlu kullanıcı algısının sürdüğü dönem arasında bir korelasyon bulunabilir
      4.x’ten 6.x’e geçerken ya da OFBiz’in gıcırdayan kutucukları gibi, dış görünüşü korunmuş ama aslında bambaşka ürünlerde olduğu gibi küçük rahatsızlıklar da beraberinde geldi
      O mühendisler çoktan ayrıldı ve hisse başına 280 doları da yanlarında götürdü
    • Artık ana işimde Jira ya da benzeri araçlar kullanmam gerekmiyor; o yüzden gerçekten merak ediyorum: sadece geliştiriciler için değil, tüm proje ekibi açısından daha iyi bir alternatif üzerinde uzlaşılmış bir seçenek var mı?
    • JIRA’nın o sürümü de yanlış yapılandırılırsa kolayca korkunç hâle gelebiliyordu
      JIRA’nın temel sorunu, düzgün yapılandırma yetkisinin her zaman yalnızca birkaç kişide olması; onların da ya üşenmesi, ya vakit bulamaması ya da sistemi her gün kullanmadıkları için umursamaması
      Elbette sorun sadece bu da değil
      Hayal etmesi zor olacak kadar yavaş ve issue’ların başka issue’lara ebeveyn olamaması gibi garip kısıtları da var

  • JIRA aşırı yavaş ve yöneticiler de onu doğru yapılandırmayı bilmiyormuş gibi görünüyordu
    Sadece kullanmış olmam bile travma yarattı

    • Bunun aracın suçu olmadığını da söyleyebilirsiniz
      Bu gezegende o aracı doğru şekilde yapılandırabilecek tek bir insan bile yok sadece
      İnsan beceriksizliği yüzünden aracı suçlayamazsınız herhalde
      Ama o zaman kimin için yapıldığı sorusu bambaşka bir konu, onu şimdilik açmayalım
    • Hep takıldığım nokta yavaşlık
      Sonuçta bir ticket sistemi özünde ticket’lar, ticket’lar arası ilişkiler ve durumlardan oluşan bir veritabanından fazlası değil
      Elbette bağlı ticket’lar, custom field’lar ve eklentiler çoksa karmaşıklık patlayabilir
      Yine de basit metin verisi ve ek dosyaları yöneten bir şeyin nasıl bu kadar dayanılmaz derecede yavaş olabildiğini anlamıyorum

  • Sonunda Jira’da Doom oynanabiliyor

    • Evet. Quake 3 Arena Multiplayer da mümkün

  • https://mattrickard.com/accidentally-turing-complete

  • Demek ki bazı Jira görevlerinin durup durmayacağını neden belirleyemediğimiz açıklanmış oluyor

    • O zaman bu, “Jira’da Doom oynayabiliyorsun” kategorisine mi giriyor?
      Jira, bunun sonucunda ortaya çıkan iblisleri öldürmek için bir pompalı tüfek de sağlıyor mu?

  • Onun yerine Azure Boards deneyin; JIRA’yı sevmeye başlarsınız
    Çünkü Microsoft’un daha kötü hâle getiremeyeceği bir yazılım yok

    • Gmail’den hep nefret ettim, hâlâ da nefret ediyorum ama geçen yıl iş değiştirip yeni şirketimin Outlook kullandığını görünce fikrim değişti
      Outlook’a duyduğum küçümsemeyi düzgün ifade edecek kelime bulmak zor; “nefret” bunun yanında çok hafif kalıyor
      E-posta alıp göndermek gibi en temel işi bile güçlükle yapıyor
      Telefona e-posta bildirimi geliyor, uygulamayı açıyorum, ortada hiçbir şey yok; aşağı çekip yeniliyorum, yine hiçbir şey olmuyor
      Genelde ancak 1 ila 15 dakika sonra görünüyor
      Outlook’ta yaptığınız her şey akıl almaz derecede zahmetli
      Çok eskiden Office 2003 zamanında da Outlook kullanmıştım ama bu kadar kötü olduğunu hatırlamıyorum. Nasıl bu kadar geriye gittiğini anlamıyorum
      Teams’e hiç girmek bile istemiyorum. O programın hangi sorunu çözmeye çalıştığını bile tam bilmiyorum
      Paylaşılan dosyalar OneDrive’da, ama Teams’te de var ve nedense Outlook’ta da var
      Bilgisayar yedek dosyalarını, yaklaşık 30 GB’lık CloneZilla imajlarını OneDrive/Teams/Outlook’a taşımam gerekti; bu sonsuza kadar sürdü ve Win11 yüklü 6 çekirdekli Ryzen dizüstünün fanı bütün süre boyunca deli gibi döndü
      Nasıl? Neden?

  • Tüm iş akışı ve orkestrasyon motorları Turing-complete’tir
    Çünkü amaçları zaten yürütme akışını otomatikleştirmektir

    • Bunların kaç tanesi sonsuza kadar çalışabilir?
      Ya da bir insan tarafından yeniden tetiklenip durduğu yerden devam ettirilebilir?
    • Ben öyle düşünmüyorum
      Birincisi, JIRA bir orkestrasyon sistemi değil
      İkincisi, iş akışının yapması gereken şey, bazı durumları dış bilgiyle ilişkilendirip bunların kolayca manipüle edilmesini sağlamaktır
      Turing-complete olması için trigger’lar ve kurallar, sonsuz sayaç gibi bir şey, iki stack, çift yönlü bir tape ya da benzeri şeyler gerekir
      Aksini kanıtlayın

  • Jira otomasyonunu seviyorum
    Jira kullanan yeni bir takıma katıldığımda, alt görevlerin story point’lerini otomatik toplayıp ebeveyn görevin story point’ine yazan ya da yeterince rafine edilmemişse ticket’ı otomatik olarak backlog’a taşıyan otomasyonlar kuruyorum
    Örneğin assignee, story point, priority, description gibi alanlar eksikse
    Daha bir sprint geçmeden takım panosu çok daha derli toplu oluyor
    Neden varsayılan olarak gelmediğini bilmiyorum ama otomasyonla düzeltmesi kolay

    • Bir ticket’ın rafine edilmiş sayılması için neden atanmış bir sorumlu gerekiyor ki?
      Sorumlu, işi üstlenen kişi olduğunda atanmalı; rafinman aşamasının bir parçası olmamalı