Jira là Turing hoàn chỉnh

(seriot.ch)

2 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp

Jira Automation có thể biểu diễn một máy Minsky với hai bộ đếm vô hạn và trạng thái lệnh hữu hạn, qua đó cho thấy tính Turing hoàn chỉnh của Jira
Trạng thái Epic đóng vai trò bộ đếm chương trình, còn số lượng Bug và Task được liên kết là hai thanh ghi; các quy tắc Automation trở thành bảng điều phối theo từng lệnh
INC và DEC được triển khai bằng cách tạo hoặc xóa issue liên kết, còn rẽ nhánh có điều kiện được quyết định bằng cách kiểm tra số issue liên kết qua quy tắc điều kiện JQL
Ví dụ phép cộng bắt đầu từ A=2, B=3, giảm Bug và tăng Task, và trong lần chạy thực tế trên *.atlassian.net đã đạt tới 5 Task cùng trạng thái dừng
Ví dụ Fibonacci giảm số vòng lặp nhờ chuyển đổi loại issue, và khi chạm giới hạn độ sâu chuỗi 10 của Jira Cloud thì có thể tiếp tục bằng cách kích hoạt lại thủ công

Máy Minsky được tạo bằng Jira Automation

Jira Automation có thể biểu diễn một Minsky register machine với hai bộ đếm vô hạn và trạng thái lệnh hữu hạn, nên có thể dùng một phép quy giản để chỉ ra tính Turing hoàn chỉnh của Jira
Mô hình được Minsky chứng minh năm 1967 chỉ gồm INC r; goto S và if r == 0 goto S else (DEC r; goto S')
Các thành phần của Jira tương ứng với từng thành phần của máy Minsky
- Register A: số issue Bug được liên kết
- Register B: số issue Task được liên kết
- Program Counter: trạng thái của một issue Epic duy nhất
- Dispatch Table: các quy tắc Jira Automation theo từng trạng thái lệnh
- Clock: các chuyển trạng thái do automation kích hoạt hoặc việc kích hoạt lại từ bên ngoài sau khi chạm giới hạn chuỗi
Trạng thái Epic mã hóa lệnh hiện tại, còn Automation rules kiểm tra số issue liên kết để chuyển sang trạng thái tiếp theo
INC và DEC được triển khai bằng cách tạo và xóa issue liên kết của loại tương ứng, còn rẽ nhánh có điều kiện được xử lý bằng quy tắc điều kiện JQL

Ví dụ thực thi và giới hạn

Chương trình cộng được cấu thành như một chương trình Minsky giảm A đồng thời tăng B
```
1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
```
Cách triển khai tối thiểu gồm một Epic, 5 issue liên kết và mỗi trạng thái lệnh có một quy tắc Automation tương ứng
Workflow và quy tắc
- Trong Jira Workflow, tạo trạng thái khởi đầu BACKLOG, sau đó là TODO, DEV, PROD, và cấu hình để mọi trạng thái đều có thể chuyển qua lại với nhau
- Tạo một Epic ở trạng thái BACKLOG
- Quy tắc TODO triển khai DEC A; if A=0 halt, else goto DEV
  - Được kích hoạt khi trạng thái Epic đổi sang TODO
  - Nếu có ít nhất một Bug liên kết thì xóa một Bug và chuyển Epic sang DEV
  - Nếu không có Bug thì chuyển Epic sang PROD để dừng
- Quy tắc DEV triển khai INC B; goto TODO
  - Được kích hoạt khi trạng thái Epic đổi sang DEV
  - Tạo một Task mới và liên kết nó với Epic
  - Chuyển Epic sang TODO
- Cả hai quy tắc đều bật "Allow rule to trigger other rules"
Giá trị khởi tạo và kết quả
- Liên kết 2 Bug và 3 Task với Epic để khởi tạo A=2, B=3
- Khi chuyển Epic sang TODO, chuỗi thực thi sẽ diễn ra như sau
```
(2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
```
- Đã được chạy trên một instance *.atlassian.net thực tế, và cuối cùng Epic đạt đến PROD với 0 Bug và 5 Task được liên kết
- Lần chạy này là kết quả Jira automation tính được 2 + 3 = 5
Cấu hình Fibonacci
- Convert Issue Type có thể đổi ngay loại issue như Bug → Story, Story → Task
- CONVERT có thể biểu diễn bằng DEC + INC, nên không mở rộng năng lực tính toán, nhưng giúp giảm bảng điều phối của các vòng lặp di chuyển để dễ xử lý các chương trình phức tạp hơn
- Fibonacci được biểu diễn thành (A, B) → (B, A+B), gồm ba thanh ghi A=Bug, B=Task, C=Story và ba trạng thái TODO, QA, DEV
```
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
```
- Trạng thái khởi đầu là A=1, B=1, C=0, và dãy 1, 1, 2, 3, 5, 8, 13, ... xuất hiện ở B, tức số lượng Task
- Khác với máy cộng, máy Fibonacci không có trạng thái dừng và sẽ chạy cho đến khi chạm giới hạn độ sâu chuỗi 10 của Jira Cloud
- Khi chạm giới hạn, người vận hành có thể kích hoạt lại Epic để tiếp tục, và chỉ với một lần chỉnh sửa trạng thái là chuỗi thực thi sẽ khởi động lại
- Jira Data Center hiển thị automation.rule.execution.timeout và các thiết lập liên quan dưới dạng thuộc tính có thể cấu hình
- Nếu giả định có thể tạo issue và thực thi quy tắc vô hạn, thì ngôn ngữ automation của Jira có thể mã hóa máy hai bộ đếm; theo tiêu chuẩn thông thường rằng máy tính vật lý cũng hữu hạn, các quota hữu hạn của Jira Cloud không bác bỏ cấu hình này

1 bình luận

GN⁺ 3 giờ trước

Ý kiến trên Hacker News

Jira hoàn toàn khủng khiếp, và có tiềm năng biến thành mọi kiểu khủng khiếp khác
- Jira là ví dụ tối hậu của khái niệm tha hóa
  Nếu Marx biết Atlassian, thì Grundrisse hẳn đã bốc cháy dữ dội
- Điều tệ nhất là các công ty làm sản phẩm quản lý công việc rốt cuộc đều đi theo hướng Jira
  Chỉ cần so sánh GitHub Issues năm 2014 với hiện tại: https://github.com/features/issues
  Và họ cứ tiếp tục, tiếp tục thêm chức năng trùng lặp
Jira rất phổ biến và cũng có API wrapper tốt cho ngôn ngữ bạn ưa dùng
Điều đáng ngạc nhiên là các lập trình viên doanh nghiệp có tinh thần hacker lại chưa tự động hóa phần lớn những việc Jira bắt làm bằng thứ như script dòng lệnh Python
Nếu tôi có thể khiến nó dễ dùng hơn cho mình hơn hẳn những người ép người khác dùng Jira, thì cục diện sẽ đảo chiều và Jira sẽ trở thành công cụ bị thúc ép để tự bảo vệ chính nó
Thỉnh thoảng tôi đã dùng Jira theo cách gần như ác ý, và nó rất tuyệt cho việc né trách nhiệm
Khi có vấn đề xảy ra, chỉ cần nói “Điều này đã được viết rất rõ trong hàng trăm cập nhật Jira của tôi, và mọi người đều đã đọc rồi đúng không?”
Giờ còn có AI nữa, nên chỉ cần bọc mọi thứ bằng script tùy chỉnh rồi để AI làm việc lặt vặt trong Jira
- Khá nhiều người đã làm vậy rồi, nhưng vấn đề là mỗi Jira instance lại là một bông tuyết fractal của các thuộc tính tùy chỉnh, chồng chất từ những đợt migration thất bại cũ kỹ và các chiến lược tổ chức mới
  API thường làm được những việc mà UI không cho phép, và vì mọi người đều vận hành theo UI nên rất dễ rơi vào những góc hỏng hóc kỳ quặc
  Ví dụ, bạn có thể không nhận ra rằng custom_field_5537 phải đi cùng custom_field_442 thì nó mới hiện trên dashboard của người khác
  Hoặc custom_field_10995 tự nhận là trường số nguyên và cũng trả về số nguyên trong XML, nhưng khi tạo công việc thì lại phải dùng một chuỗi hằng ma thuật không được tài liệu hóa, còn khi cập nhật thì lại không cần như vậy
  Web UI thì không làm thế, trong HTML và request chỉ là số nguyên bình thường, còn 80% chuỗi chỉ khớp với văn bản hiển thị trong dropdown
  Tự động hóa Jira là trải nghiệm lập trình tệ nhất tôi từng gặp
  Chắc chắn có những thiết lập đơn giản hơn và có thể khá dễ, nhưng ngay cả vậy cũng quá mức
  Đáng buồn là công sức bỏ ra vẫn hoàn toàn xứng đáng. Rất khuyến nghị
- Ở chỗ làm cũ, tôi đã tạo vài công cụ tiết kiệm thời gian qua API, và tất cả đều là những shell script nhỏ
  Chúng tôi thêm một trường văn bản tùy chỉnh mô tả dễ đọc cho con người vào mỗi ticket, và khi bản phát hành được triển khai thì script deploy sẽ tự động điền timestamp
  Chúng tôi phát hành từng ticket theo từng đơn vị công việc, và mỗi ngày xử lý nhiều ticket
  Kết hợp với các bộ lọc tùy chỉnh, Jira cung cấp changelog dễ đọc cho con người cho từng board và cho toàn công ty, và các thông điệp này được chuyển sang Slack cho phía kinh doanh để mọi người biết cái gì đang được triển khai
  Nó cũng là nhật ký kiểm toán phát hành có thể tìm kiếm, gắn với các thay đổi mã nguồn
  Quy trình triển khai cũng chuyển trạng thái ticket trên Jira, nên lập trình viên chỉ cần merge ticket vào main là nó sẽ được deploy và cũng hoàn tất trên Jira
  Cũng có nhiều script nhỏ tự động tạo ticket cho các tác vụ lặp lại
  Trong nhiều năm nó rất vững chắc, và có lẽ đến giờ vẫn đang chạy
  Quy ước đặt tên trường tùy chỉnh thì không hay lắm, nhưng nếu đội ngũ kiểm soát được cấu hình Jira thì không khó để mọi thứ giữ cùng một chuẩn
  Ban đầu tôi không thích Jira, và ngày xưa nó có nhiều vấn đề, nhưng dạo này nếu cấu hình tốt thì cũng không tệ đến vậy
  Nếu là công ty của tôi thì tôi sẽ không chọn nó, nhưng với tư cách người đã dùng nó như lập trình viên, quản trị viên, người dùng cuối và người phát triển công cụ nội bộ, thì một khi đã được cấu hình và chạy ổn, nó thường không gây cản trở nhiều
- “Bọc mọi thứ bằng script tùy chỉnh rồi để AI làm việc lặt vặt trong Jira” nghe như thể sự cồng kềnh của Jira vẫn chưa đủ lớn
  Nếu thêm nhiều văn bản hơn, Jira bằng cách nào đó sẽ luôn tự động chạy mọi thứ trên đống văn bản ấy, nên nó sẽ còn chậm hơn
  Nếu công ty cần sưởi ấm thì cứ dùng Jira
- Từ rất lâu trước đây tôi đã chuyển sang JetBrains YouTrack, và chúng tôi dùng API của nó để làm những việc như vậy
  Nó khá linh hoạt, và nhờ AI mà còn cởi mở hơn nữa
- Cả công ty chúng tôi thực tế vận hành bằng Jira
  Hầu hết quy trình đều phụ thuộc vào Jira, và một số chuyển trạng thái nhất định sẽ kích hoạt webhook cho tự động hóa
  Ngay khi có quyền truy cập AI, một trong những việc đầu tiên tôi làm là tạo Jira MCP
  Giờ tôi gần như cố không đụng trực tiếp vào Jira nữa, mà bảo Claude tạo issue Jira, viết comment, tạo sub-task, liên kết issue, v.v.
  Trước đây tôi luôn thấy sợ mỗi khi phải nghiên cứu cách triển khai và tách nó thành các đầu việc
  Vì càng chia nhỏ chi tiết thì càng phải tạo nhiều issue Jira để chứa từng phần việc đó
  Giờ chỉ cần ghi mọi thứ vào file rồi giao việc lặt vặt trên Jira cho mô hình ngôn ngữ lớn
Khi quay lại chỗ làm cũ, tôi thấy họ vẫn đang dùng JIRA
Lúc phỏng vấn thì dĩ nhiên tôi nói kiểu “À JIRA à, vẫn còn dùng cái đó sao? Dùng được chứ”
Thực tế là vẫn dùng được, nhưng nhìn JIRA bản mới đúng là bị sốc thật
Có phải đến cả nghìn phiền toái lặt vặt, và một trong những thứ tệ nhất là khi bạn cố double-click để chọn văn bản thì nó đột nhiên chuyển trường đó sang chế độ chỉnh sửa
Thứ tôi nhớ là JIRA Server 4.0, và có thể ôn lại ký ức ở đây: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
Nếu phóng to đủ mức thì mỗi issue có tiêu đề, loại, phiên bản sửa lỗi, phiên bản bị ảnh hưởng, v.v. và cấu trúc nối thẳng tới phần bình luận. Rất đơn giản
- Vụ double-click rồi vào chế độ chỉnh sửa là thật
  Bực mình kinh khủng. Ngay cả thao tác với văn bản cơ bản cũng làm sai
  Thế mà có quản lý dự án lại bảo họ thích như vậy
  Vì họ không dùng kiểu double-click rồi kéo để chọn cả từ
  Như thường lệ, người dùng thành thạo hơn lại bị kéo xuống chỉ để phục vụ sự tiện lợi của những người chỉ vừa đủ biết dùng máy tính
- Phản ứng kiểu “JIRA á, vẫn còn dùng cái đó sao?” nghe khá kỳ lạ
  Làm tôi tự hỏi có phải mình bỏ lỡ gì đó hay bị rơi vào hố thời gian không
  Tôi không hiểu sao lại nói về Jira như thể nó là Visicalc
  Giờ tôi không còn làm ở công ty IT nữa, nên có thể trong 2 năm qua đã bỏ lỡ một biến động lớn nào đó
- Có thể tìm ra mối tương quan giữa giá cổ phiếu và nhận thức tích cực của người dùng trong giai đoạn sản phẩm còn được duy trì
  Khi chuyển từ 4.x sang 6.x, nó cũng mang theo những phiền toái lặt vặt, giống như các hộp OFBiz ọp ẹp và những sản phẩm hoàn toàn khác chỉ được chỉnh cho giống về bề ngoài
  Mấy kỹ sư đó đã rời đi từ lâu, và họ cũng mang theo cả 280 đô một cổ phiếu
- Giờ tôi không còn phải dùng Jira hay công cụ tương tự trong công việc chính nữa, nên thật sự tò mò là có sự đồng thuận nào về lựa chọn thay thế tốt hơn từ góc nhìn của toàn bộ nhóm dự án, chứ không chỉ riêng lập trình viên không?
- Ngay cả phiên bản JIRA đó cũng có thể dễ dàng trở nên kinh khủng nếu cấu hình sai
  Vấn đề cốt lõi của JIRA là quyền cấu hình cho tử tế lúc nào cũng chỉ nằm trong tay một số ít người, mà những người đó thì lười, hoặc không có thời gian, hoặc không dùng hằng ngày nên không quan tâm
  Tất nhiên vấn đề không chỉ có vậy
  Nó chậm đến mức khó tin, và còn có những hạn chế kỳ quặc như issue không thể làm cha của một issue khác
JIRA quá chậm, và có vẻ như các quản trị viên chẳng biết cấu hình cho đúng
Chỉ riêng việc từng dùng nó thôi cũng đã thành chấn thương tâm lý
- Cũng có thể nói không phải lỗi của công cụ
  Chỉ là trên hành tinh này không có lấy một người nào biết cách cấu hình nó cho đúng
  Chắc không thể quy trách nhiệm cho công cụ chỉ vì sự bất tài của con người
  Còn chuyện nó được tạo ra cho ai thì lại là vấn đề hoàn toàn khác, và giờ chưa nên bàn đến
- Thứ luôn khiến tôi vướng lại là độ chậm
  Về bản chất, hệ thống ticket chẳng hơn gì một cơ sở dữ liệu chứa ticket, quan hệ giữa các ticket, và trạng thái
  Dĩ nhiên nếu có nhiều ticket liên kết, custom field, và plugin thì độ phức tạp có thể bùng nổ
  Nhưng tôi vẫn không hiểu nổi tại sao một thứ chỉ xử lý dữ liệu văn bản đơn giản và tệp đính kèm lại có thể chậm đến mức không chịu nổi như vậy
Cuối cùng thì giờ có thể chơi Doom trong Jira rồi
- Đúng vậy. Quake 3 Arena Multiplayer cũng chơi được luôn
https://mattrickard.com/accidentally-turing-complete
Vậy là giải thích được vì sao không thể xác định một tác vụ Jira có dừng hay không
- Thế thì có được tính là “chơi Doom trong Jira” không?
  Jira có cung cấp luôn shotgun bơm tay để giết lũ quỷ do chính nó tạo ra không?
Cứ thử dùng Azure Boards đi rồi bạn sẽ lại yêu JIRA
Vì trên đời này không có phần mềm nào mà Microsoft không thể làm cho tệ hơn
- Tôi luôn ghét Gmail và giờ vẫn ghét, nhưng sau khi đổi việc năm ngoái và công ty mới dùng Outlook thì tôi đổi ý
  Khó mà tìm được từ ngữ diễn tả đúng mức sự khinh bỉ tôi dành cho Outlook, và từ “ghét” còn chưa đủ để bắt đầu
  Ngay cả việc cơ bản nhất là nhận và gửi email nó cũng làm như cực hình
  Điện thoại báo có email mới, tôi mở ứng dụng ra thì không thấy gì, kéo xuống để làm mới cũng không có chuyện gì xảy ra
  Thường phải 1 đến 15 phút sau nó mới hiện ra
  Mọi việc làm trong Outlook đều phiền phức đến khủng khiếp
  Ngày xưa thời Office 2003 tôi cũng từng dùng Outlook, nhưng tôi không nhớ nó tệ đến mức này. Không hiểu sao nó lại thụt lùi được như vậy
  Còn Teams thì tôi chẳng muốn bắt đầu nói tới. Tôi cũng không rõ cái chương trình đó đang cố giải quyết vấn đề gì
  File chia sẻ thì có trên OneDrive, lại có trong Teams, và vì lý do nào đó còn có cả trong Outlook
  Tôi đã phải chuyển các file sao lưu máy tính, khoảng 30GB image CloneZilla, lên OneDrive/Teams/Outlook, việc đó mất gần như vô tận, còn quạt của chiếc laptop Ryzen 6 nhân chạy Win11 thì quay như điên suốt thời gian đó
  Làm sao? Tại sao?
Mọi công cụ workflow và orchestration đều là Turing-complete
Vì mục đích của chúng vốn là tự động hóa luồng thực thi
- Trong số đó có bao nhiêu cái có thể chạy vô hạn?
  Hoặc để con người kích hoạt lại và tiếp tục từ chỗ đã dừng?
- Tôi không nghĩ vậy
  Thứ nhất, JIRA không phải orchestration
  Thứ hai, việc một workflow cần làm là gắn một số trạng thái với thông tin bên ngoài và giúp thao tác chúng dễ dàng
  Để Turing-complete thì cần có trigger và rule, một thứ như bộ đếm vô hạn, hai stack, băng hai chiều, hoặc tương tự
  Hãy chứng minh tôi sai đi
Tôi thích tự động hóa trong Jira
Khi vào một đội mới dùng Jira, tôi sẽ thiết lập các automation như tự động cộng story point của các sub-task để điền story point cho task cha, hoặc tự động đưa ticket về backlog nếu nó thiếu đủ thuộc tính để được coi là đã refinement
Ví dụ như thiếu assignee, story point, mức ưu tiên, mô tả, v.v.
Chỉ sau một sprint, board của cả đội sẽ gọn gàng hơn hẳn
Tôi không hiểu sao đó không phải mặc định, nhưng sửa bằng automation thì dễ
- Tại sao để coi là ticket đã refinement thì lại cần gán người phụ trách?
  Người phụ trách nên là người nhận việc đó khi họ quyết định làm, chứ không nên là một phần của giai đoạn refinement

Jira là Turing hoàn chỉnh

Máy Minsky được tạo bằng Jira Automation

Ví dụ thực thi và giới hạn

Workflow và quy tắc

Giá trị khởi tạo và kết quả

Cấu hình Fibonacci

Bài viết liên quan

1 bình luận

Ý kiến trên Hacker News