Jika Anda bekerja di perusahaan IT, maka kemungkinan besar proses Anda dibangun di sekitar produk Atlassian yang terkenal - Jira. Ada banyak pelacak tugas di pasar untuk memecahkan masalah yang sama, termasuk solusi open-source (Trac, Redmine, Bugzilla), tetapi mungkin Jira adalah yang paling banyak digunakan saat ini.

Nama saya Dmitry Semenikhin, saya seorang pemimpin tim di Badoo. Dalam serangkaian artikel singkat, saya akan memberi tahu Anda dengan tepat bagaimana kami menggunakan Jira, bagaimana kami menyesuaikannya untuk proses kami, hal-hal baik apa yang "kacau" di atas, dan bagaimana kami mengubah pelacak masalah menjadi pusat komunikasi tunggal untuk tugas dan menyederhanakan hidup kami. Pada artikel ini, Anda akan melihat aliran kami di dalam, belajar bagaimana Anda dapat "memutar" Jira Anda, dan membaca tentang fitur tambahan alat yang mungkin tidak Anda ketahui.

Artikel ini terutama ditujukan bagi mereka yang sudah menggunakan Jira, tetapi mungkin mengalami kesulitan mengintegrasikan fitur standarnya ke dalam proses yang ada di perusahaan. Juga, artikel ini mungkin bermanfaat bagi perusahaan yang menggunakan pelacak tugas lain, tetapi telah menemui beberapa batasan dan sedang mempertimbangkan perubahan keputusan. Artikel ini tidak dibangun berdasarkan prinsip "masalah - solusi", di dalamnya saya menjelaskan alat dan fitur yang ada yang kami bangun di sekitar Jira, serta teknologi yang kami gunakan untuk mengimplementasikannya.

Fitur tambahan dari Jira

Untuk membuat teks berikut lebih mudah dipahami, mari kita cari tahu alat apa yang disediakan Jira untuk implementasi Wishlist yang tidak standar - yang melampaui fungsi standar Jira.

API SISA

Secara umum, panggilan perintah API adalah permintaan HTTP ke URL API yang menunjukkan metode (GET, PUT, POST dan DELETE), perintah, dan badan permintaan. Badan permintaan, serta respons API, dalam format JSON. Contoh permintaan yang mengembalikan representasi JSON dari tiket:

GET /rest/api/latest/issue/{ticket_number} 

Menggunakan API, Anda bisa, menggunakan skrip dalam bahasa pemrograman apa pun:

• buat tiket;
  
• memodifikasi properti tiket apa pun (bawaan dan kustom);
  
• tulis komentar;
  
• menggunakan JQL (bahasa kueri bawaan) untuk menerima daftar tiket apa pun;
  
• dan masih banyak lagi.
  

Dokumentasi API rinci tersedia di sini .

Kami menulis klien Jira API tingkat tinggi kami sendiri di PHP, yang mengimplementasikan semua perintah yang kami butuhkan. Berikut adalah contoh perintah untuk bekerja dengan komentar:

 public function addComment($issue_key, $comment) {  return $this->_post("issue/{$issue_key}/comment", ['body' => $comment]); } public function updateComment($issue_key, $comment_id, $new_text) {  return $this->_put("issue/{$issue_key}/comment/{$comment_id}", ['body' => $new_text]); } public function deleteComment($issue_key, $comment_id) {  return $this->_delete("issue/{$issue_key}/comment/{$comment_id}"); } 

Situs web

Menggunakan webhook, Anda dapat mengonfigurasi panggilan fungsi panggilan balik eksternal pada host Anda ke berbagai acara di Jira. Pada saat yang sama, Anda dapat mengonfigurasikan sebanyak mungkin aturan yang Anda inginkan sehingga URL yang berbeda akan “bergerak-gerak” untuk acara yang berbeda dan untuk tiket yang cocok dengan filter yang ditentukan dalam webhook. Antarmuka konfigurasi webhooks tersedia untuk administrator Jira.

Akibatnya, Anda dapat membuat aturan seperti ini:

Nama : "SRV - Fitur Baru dibuat / diperbarui"
URL : www.myremoteapp.com/webhookreceiver
Lingkup : Proyek = SRV DAN ketik ('Fitur Baru')
Acara : Masalah Diperbarui, Masalah Dibuat

Dalam contoh ini, URL yang ditentukan akan dipanggil untuk pembuatan tiket dan mengubah acara yang sesuai dengan filter Lingkup . Pada saat yang sama, isi permintaan akan berisi semua informasi yang diperlukan tentang apa yang sebenarnya telah berubah dan peristiwa apa yang telah terjadi.

Penting untuk dipahami bahwa Jira tidak menjamin acara Anda akan dikirimkan. Jika URL eksternal tidak merespons atau menjawab dengan kesalahan, ini tidak akan terlihat di mana pun (kecuali untuk log, mungkin). Oleh karena itu, pengendali event webhook harus seandal mungkin. Misalnya, Anda dapat mengantri acara dan mencoba memprosesnya hingga berhasil. Ini akan membantu menyelesaikan masalah dengan layanan sementara yang tidak tersedia, misalnya, setiap basis data eksternal yang diperlukan untuk pemrosesan acara yang benar.

Dokumentasi terperinci tentang webhook tersedia di sini .

Penulis Naskah

Ini adalah plugin untuk Jira, alat yang sangat kuat yang memungkinkan Anda untuk menyesuaikan banyak Jira (termasuk kemampuan untuk mengganti webhooks). Menggunakan plugin ini membutuhkan pengetahuan tentang Groovy. Keuntungan utama alat ini bagi kami adalah Anda dapat menanamkan logika khusus dalam aliran online. Kode skrip Anda akan dieksekusi segera di lingkungan Jira sebagai respons terhadap tindakan tertentu. Misalnya, Anda dapat membuat tombol Anda sendiri di antarmuka tiket, mengkliknya akan membuat tiket terkait dengan tugas saat ini atau menjalankan tes unit untuk tugas ini. Dan jika tiba-tiba terjadi kesalahan, Anda sebagai pengguna akan segera mengetahuinya.

Mereka yang tertarik dapat membaca dokumentasi .

Flow: apa yang disembunyikan di bawah tenda

Dan sekarang tentang bagaimana kami menerapkan fitur tambahan Jira dalam proyek kami. Pertimbangkan ini dalam konteks melalui tiket aliran khas kami dari penciptaan ke penutupan. Pada saat yang sama, saya akan memberi tahu Anda tentang aliran itu sendiri.

Buka / backlog

Jadi, pertama tiket masuk ke tumpukan tiket baru dengan status Open . Selanjutnya, pemimpin komponen, setelah melihat tiket baru di dashboard-nya, membuat keputusan: menetapkan tiket sekarang untuk pengembang atau mengirimkannya ke tumpukan tiket yang dikenal (status Backlog ) untuk menetapkannya nanti, ketika pengembang gratis muncul dan tiket prioritas yang lebih tinggi akan ditutup. Ini mungkin tampak aneh, karena tampaknya logis untuk melakukan yang sebaliknya: membuat tiket dalam status Backlog , dan kemudian menerjemahkannya ke status Terbuka. Tetapi kami telah mengakar dengan tepat skema ini. Ini memungkinkan Anda untuk dengan mudah mengkonfigurasi filter untuk mengurangi waktu keputusan untuk tiket baru. Contoh filter JQL yang menunjukkan tugas baru untuk arahan:

Project = SRV AND assignee is EMPTY AND status in (Open)

Sedang berlangsung

Ketika sebuah tiket menabrak pengembang, hal pertama yang dia dekomposisi. Hasil dekomposisi adalah ide pengembang tentang cara mengatasi masalah dan berapa lama solusi akan berlangsung. Setelah semua detail utama diklarifikasi, tiket ditransfer ke status Sedang Berlangsung , dan pengembang mulai menulis kode.

Merupakan kebiasaan bagi kami untuk mengatur tanggal tenggat ke tugas pada saat ditransfer ke status In Progress. Jika pengembang tidak melakukan ini, ia akan menerima pengingat di messenger perusahaan HipChat. Skrip khusus setiap dua jam:

• menggunakan Jira REST API memilih tiket dalam status sedang berlangsung dengan bidang tenggat waktu kosong ( proyek = SRV DAN status = 'Sedang Berlangsung' DAN duedate KOSONG );
  
• memilih tiket yang tidak lengkap dengan tanggal jatuh tempo yang lebih tua dari tanggal saat ini ( proyek = SRV DAN status = 'Sedang Berlangsung' DAN duedate bukan KOSONG DAN duedate <now () );
  
• mengenali pengembang untuk setiap tiket dengan membaca bidang yang sesuai dalam tiket, serta pimpinan pengembang;
  
• mengelompokkan tiket oleh pengembang dan prospek dan mengirimkan pengingat ke HipChat menggunakan API-nya.
  

Setelah melakukan semua yang diperlukan, pengembang mendorong cabang menjadi lobak umum. Dalam hal ini, Git hook pasca-terima akan menyala, yang melakukan banyak hal menarik:

• Nama cabang Git, serta komentar tentang komitmen, diperiksa untuk kepatuhan terhadap peraturan kami;
  
• diperiksa bahwa tiket yang terkait dengan cabang tidak ditutup (Anda tidak dapat memasukkan kode baru ke dalam tiket tertutup);
  
• Sintaks file PHP yang dimodifikasi diperiksa (PHP -l file_name.php );
  
• pemformatan diperiksa;
  
• jika tiket tempat cabang didorong dalam status Open , maka secara otomatis akan ditransfer ke status In Progress ;
  
• tiket dilampirkan ke cabang, entri yang sesuai dibuat di bidang kustom dari tiket Komit menggunakan Jira API. Ini terlihat seperti ini:
  

( branchdiff adalah tautan ke diff cabang dengan kepala dari mana cabang saat ini berasal dari alat peninjau kode Codeisok kami);

• sebuah komentar dibuat di tiket dengan semua komitmen dalam dorongan ini.
  
  
  
  (Aida adalah nama kondisional dari kompleks otomasi kami untuk bekerja dengan Jira, Git dan tidak hanya. Dari nama inilah komentar otomatis muncul di tiket. Kami menulis lebih banyak tentang Aida dalam artikel ).
  Sebuah klik pada hash dari commit akan terbuka berbeda dengan revisi cabang sebelumnya (saya akan tunjukkan seperti di bawah);
  
• ia memeriksa apakah ada file di cabang yang mungkin memerlukan terjemahan ke bahasa yang didukung (misalnya, templat halaman web), dan jika ada, maka bidang tiket kustom \ Lexed diatur ke New \ Changed. Ini memastikan bahwa tiket tidak akan diproduksi tanpa terjemahan yang lengkap;
  
• nama karyawan yang mendorong cabang ditambahkan ke daftar pengembang (bidang khusus tiket Pengembang )
  

Sedang ditinjau

Setelah menulis kode dan memastikan bahwa semua persyaratan untuk tugas tersebut terpenuhi dan tes tidak rusak, pengembang memberikan tiket kepada peninjau (Status Peninjauan ). Biasanya, pengembang memutuskan siapa yang akan meninjau tiketnya. Kemungkinan besar, itu akan menjadi pengembang lain yang fasih di bagian kanan kode. Tinjauan dilakukan menggunakan alat Codeisok , yang segera dibuka dengan perbedaan yang diinginkan dengan mengklik tautan branchdiff di bidang tiket Komit atau dalam komentar sebagai hash komit dalam komentar.

Peninjau melihat sesuatu seperti ini:


Setelah menyelesaikan peninjauan, peninjau menekan tombol Selesai , dan, antara lain, pada saat ini hal berikut terjadi:

• menggunakan JIra API, komentar dibuat di tiket dengan komentar dari pengulas dalam konteks kode. Itu terlihat seperti ini:
  

• jika ada komentar pada kode dan peninjau memutuskan untuk membuka kembali tiket, pengembang akan menerima pemberitahuan tentang ini di HipChat (ini dilakukan dengan menggunakan aturan webhook, yang berfungsi pada pembukaan kembali);
  
• Bidang tiket Reviewer sudah diisi.
  

Terselesaikan

Selanjutnya, jika peninjauan berhasil, tiket dikirim ke jaminan teknis QA dalam status Terselesaikan . Tetapi pada saat yang sama, menggunakan webhook untuk acara yang diselesaikan, tes otomatis pada kode cabang diluncurkan di latar belakang. Setelah beberapa menit, sebuah komentar baru akan muncul di tiket, yang akan memberi tahu Anda tentang hasil tes.



Juga, kapan saja, Anda dapat secara manual memulai uji coba berulang dengan mengklik tombol Uji unit khusus di menu tiket. Setelah sukses, komentar baru akan muncul di tiket, mirip dengan yang sebelumnya.


Bahkan, tombol ini adalah salah satu status tugas tambahan dalam alur kerja Jira, terjemahan yang memicu skrip Groovy untuk plugin ScriptRunner. Skrip memanggil URL eksternal, yang memulai uji coba, dan jika URL berhasil merespons, tiket kembali ke status sebelumnya (dalam kasus kami, Diselesaikan ).

In Shot / In Shot - OK

Tugas ini pertama kali diuji dalam lingkungan devel. Jika semuanya baik-baik, bidikan dibuat (misalnya, dengan mengklik tautan Buat bidikan di bidang Komit ) - direktori pada server khusus tempat perubahan dari tiket disalin yang berdekatan dengan master saat ini. Server bekerja dengan data produksi: basis data dan layanan adalah sama yang melayani pengguna nyata. Dengan demikian, penguji dapat membuka situs web atau terhubung ke foto menggunakan klien seluler dan "mengisolasi" fitur dalam lingkungan produksi. "Terisolasi" berarti tidak ada kode / fungsi lain, kecuali yang baru dari cabang dan master saat ini, dieksekusi. Oleh karena itu, tahap pengujian ini mungkin yang utama, karena memungkinkan teknisi QA untuk menemukan masalah secara langsung dalam masalah pengujian.

Sumberdaya shot diakses menggunakan URL khusus yang dibuat dalam skrip pembuatan shot dan ditempatkan di header tiket menggunakan Jira API. Akibatnya, kami melihat tautan ke situs, panel admin, log, dan alat lain yang dieksekusi di lingkungan pengambilan gambar:



Juga, pada saat pengambilan gambar, sebuah skrip diluncurkan yang menganalisis konten dari file yang diubah dan membuat permintaan untuk terjemahan token baru yang ditemukan. Setelah terjemahan selesai, nilai bidang Lexems diubah menjadi Selesai dan tiket dapat ditambahkan ke build.

Jika tes yang dilakukan berhasil, maka tiket ditransfer ke status Di Tembakan - OK.

Dalam Bangun / Bangun - OK

Kami mengunggah kode dua kali sehari - pagi dan sore hari. Untuk melakukan ini, cabang-bangunan khusus dibuat, yang pada akhirnya akan digabungkan dengan master dan diletakkan "dalam pertempuran".

Pada saat membangun cabang build, skrip khusus menggunakan kueri JQL menerima daftar tiket dalam status In Shot - OK dan mencoba untuk membekukannya di cabang build ketika semua persyaratan berikut dipenuhi:

• terjemahan untuk tiket selesai atau tidak ada yang perlu diterjemahkan ( Lexems in ('No', 'Done') );
  
• pengembang hadir di tempat kerja (sistem merger otomatis memeriksa pada pangkalan internal apakah pengembang sedang berlibur atau cuti sakit, dan jika demikian, tiket hanya dapat dibekukan secara manual oleh insinyur rilis atau pengembang yang bertanggung jawab lainnya, yang ditunjukkan dalam bidang khusus Wakil Pengembang ; pemimpin pengembang yang tidak hadir dalam kasus ini menerima pemberitahuan bahwa tiket tidak dapat ditambahkan secara otomatis ke build);
  
• tiket tidak memiliki bendera Up in Build yang ditetapkan oleh Developer (ini adalah bidang khusus tiket yang memungkinkan pengembang menentukan kapan tiket akan pergi ke build);
  
• cabang tiket tidak bergantung pada cabang lain yang belum mencapai master atau build saat ini. Kami melakukan yang terbaik untuk menghindari situasi ini, tetapi kadang-kadang ini terjadi ketika pengembang membuat cabang sendiri bukan dari master, tetapi dari cabang tiket lain, atau ketika ia membekukan cabang lain untuk dirinya sendiri. Ini juga dapat dilakukan secara kebetulan, jadi kami memutuskan bahwa perlindungan tambahan tidak akan merugikan.
  

Perlu dicatat bahwa penggabungan otomatis mungkin tidak terjadi karena konflik penggabungan. Dalam hal ini, tiket secara otomatis ditransfer ke status Reopen dan ditugaskan ke pengembang, yang tentangnya ia segera menerima pemberitahuan di HipChat, dan pesan yang sesuai ditambahkan ke komentar tiket. Setelah menyelesaikan konflik, tiket kembali ke gedung.

Jika semuanya baik-baik saja dan cabang tiket dibekukan dalam build, tiket secara otomatis ditransfer ke status In Build , dan nama build ditulis di bidang khusus tiket Build_Name .


Lebih lanjut, dengan menggunakan nilai ini, mudah untuk mendapatkan daftar tiket yang dipasang pada setiap bangunan. Misalnya, untuk mencari seseorang untuk disalahkan jika terjadi kesalahan.

Pada tahap selanjutnya, insinyur QA juga memeriksa apakah kode tugas berfungsi dengan benar bersama dengan tugas lain dalam pembuatan. Jika semuanya baik-baik saja, tiket secara manual diatur ke Dalam Bangun - OK.

On Production / On Production - OK / Tertutup

Selanjutnya, saat dibangun, seluruh rangkaian pengujian kami dijalankan (Unit, integrasi, Selenium-, dll.). Jika semuanya baik-baik saja, build dibekukan dalam master, dan kode ditata untuk produksi. Tiket ditransfer ke status On Production.

Selanjutnya, pengembang (atau pelanggan) memastikan bahwa fitur berfungsi dengan benar pada produksi, dan menetapkan status tiket Pada Produksi - OK.

Setelah dua minggu, tiket dalam status On Production - OK secara otomatis ditransfer ke status Closed , jika seseorang belum melakukan ini secara manual sebelumnya.

Anda juga perlu menyebutkan status tambahan tempat tiket berada:

• Persyaratan - ketika tidak mungkin mendapatkan dengan cepat dari pelanggan klarifikasi yang diperlukan pada tugas tersebut, dan tanpa mereka bekerja lebih lanjut pada tiket tidak mungkin, tiket ditransfer ke status ini dan ditugaskan kepada orang yang perlu memberikan penjelasan;
  
• Ditangguhkan - jika pekerjaan tiket ditangguhkan, misalnya, jika pengembang diblokir oleh tugas-tugas tim yang berdekatan atau terpaksa beralih ke tugas yang lebih mendesak;
  
• Dibuka kembali - tugas dapat ditemukan kembali kepada pengembang setelah ditinjau, setelah pengujian, setelah upaya yang gagal untuk menggabungkan cabang dengan master.
  

Hasilnya, diagram alur kerja kami yang disederhanakan tampak seperti ini:

Tiket - pusat komunikasi untuk tugas tersebut

Sebagai hasil dari melewati tiket melalui alur, tajuknya memperoleh kira-kira bentuk berikut:



Apa lagi yang menarik di sini yang telah kami sesuaikan untuk kami sendiri dan yang belum saya sebutkan?

• Komponen - digunakan untuk mengelompokkan tiket di dalam departemen besar. Subkelompok yang berbeda bertanggung jawab untuk komponen yang berbeda dan, karenanya, pada dasbornya mereka hanya melihat tugas untuk komponen mereka. Misalnya, saya bisa mendaftar semua bug terbuka untuk komponen tim saya dengan pertanyaan ini:
  
  

   Project = SRV AND type = Bug AND status = Open AND component in componentsLeadByUser(d.semenihin) 

  
  
• Review - apakah review kode diperlukan. Diperlukan bawaan. Jika nilai bidang diatur ke Tidak, tiket akan segera mendapatkan status Terselesaikan.
  
  QA - Apakah tester perlu verifikasi. Diperlukan bawaan. Jika nilai bidang diatur ke Tidak, tiket akan langsung menuju ke status Suntingan - OK.
  
  Sprint - dalam kasus kami, ini hanya relevan untuk tugas-tugas dengan tipe Fitur Baru, sebuah rencana yang kami buat sebelumnya selama seminggu.
  
• Tanggal jatuh tempo - pengembang menentukan tanggal kapan tiket akan diproduksi. Dipamerkan sebelum mulai mengerjakan tugas.
  
• Situasi - pada kenyataannya, log pendek dengan deskripsi singkat tentang status tugas saat ini. Misalnya, "20/08 Saya menunggu terjemahan" , "21/08 Klarifikasi diperlukan dari pelanggan pada masalah X" . Ini membantu untuk melihat ringkasan singkat tugas dalam daftar tugas lain.
  
• Msg4QA - informasi untuk insinyur QA, yang dibagikan pengembang untuk menyederhanakan proses pengujian
  

Kami mencoba untuk melakukan diskusi tentang masalah kontroversial dengan direktur tugas dalam komentar tiket, dan tidak "mengotori" klarifikasi penting melalui surat dan kurir instan. Namun, jika diskusi berlangsung "di samping", sangat diinginkan untuk menyalin apa yang telah Anda setujui ke dalam tiket.

Selain teks "manusia", seperti yang saya sebutkan di atas, banyak hal yang ditulis secara otomatis dalam komentar menggunakan API:

• berkomitmen
  
• ulasan hasil;
  
• hasil uji coba.
  

Terkadang komentar otomatis dapat mengganggu, misalnya, dengan manajer produk. Karena itu, kami membuat skrip JS sederhana yang menambahkan tombol ke antarmuka Jira dan memungkinkan Anda untuk meminimalkan semua komentar otomatis, hanya menyisakan komentar manusia. Akibatnya, komentar otomatis yang diperkecil terlihat kompak.

Apa lagi

API webhooks Jira :

• HipChat, - ( );
  
• HipChat ( , );
  
• ( ) ( ; );
  
• ; , ;
  
• In progress ;
  
• , «» (, On Review), ;
  
• , Jira (, «d.semenihin (Day off)»). .
  

Ringkasan

Jira — , , . , , . Jira , .

— . Jira , Jira. , - .

Terima kasih atas perhatian anda!