Satu bot dari semua kekhawatiran

Sampai konvensi "Tentang Perlindungan Hak-Hak Orang Tidak Manusiawi" telah diadopsi, Anda perlu menggunakan ini dan memberikan rutinitas kerja kepada bot. Masuk akal untuk memulai sekarang, atau setelah 5 tahun, pemberontakan mobil akan dimulai, gugatan massal untuk menghina perasaan bot dengan tugas-tugas membosankan akan mengisi pengadilan untuk mengatur hubungan manusia-mesin. Jadi cepatlah.

Rutin konservatif dan metode kerja, kepatuhan pada pola yang telah mapan, berubah menjadi kebiasaan mekanis. 6 huruf.

Ada pekerjaan yang tidak ingin Anda lakukan, tetapi Anda harus melakukannya. Artikel ini tidak akan memiliki sisipan besar dengan kode dan instruksi tentang cara membuat bot Anda dari awal. Saya lebih baik memberi tahu Anda bagaimana proses rilis bekerja di Pizza Dodo kami, bagaimana kami mengotomatisasi dan mempercepatnya, memberikan beberapa rutinitas yang membosankan ke bot kami yang ditulis dalam C #. Saya akan memperhatikan fungsionalitas dan logika bot. Ini akan keren jika materi ini menginspirasi Anda untuk menulis asisten Anda yang akan membuat hidup lebih mudah bagi Anda dan kolega Anda.

Beberapa tahun yang lalu kami merilis satu rilis sekali seminggu. Pada Mei 2018, memiliki tingkat maksimum 147 jam untuk rilis, kami menetapkan tujuan untuk rilis setiap hari. Sekarang minimum kami: empat jam untuk rilis, tetapi ini tidak sering terjadi. Kami ingin memperbaiki catatan dan dapat mengurangi seluruh proses dengan menekan satu tombol.

Siklus rilis

Sekarang di Dodo IS, tujuh tim bergiliran merilis rilis. Satu orang dari tim menjadi "beruntung" - relizmen. Relizmen sebagai pilot pesawat terbang: dia memiliki banyak tuas dan perangkat yang harus dia pakai dengan terampil untuk meluncurkan pembaruan berikutnya. Kami berpikir dan memutuskan: "Sudah waktunya untuk melakukan autopilot, dan kami lebih baik menghabiskan waktu kami pada sesuatu yang lebih menarik daripada mengisi tabel membosankan dengan statistik dan melacak uji coba otomatis."

Jadi, untuk menjadi relisman, penting bahwa giliran datang ke tim Anda. Agar semuanya jelas dan tidak ada yang bingung, kami menempelkan stiker dengan nama-nama tim di dinding. Tim pelepasliaran menerima mahkota kehormatan, yang kami bergerak dengan pegangan setiap waktu.

Setelah menerima tanda mahkota hitam, Relismain harus ingat di mana daftar langkah pelepasan berada. Selanjutnya: diingat -> ditemukan -> membuat salinan dari templat dan, akhirnya, membuka daftar periksa dalam sistem Kaiten. Kaiten adalah papan elektronik di mana dalam bentuk kartu kami menempatkan dan memantau status tugas dalam pengembangan. Untuk pengembang baru, prosedur ini secara keseluruhan sangat tidak terlihat. Dan bagaimana Anda tahu ke mana harus mencari lembar cek ini dan dari mana harus memulai ketika tidak ada petunjuk?

Setelah mengumpulkan tekad kami, kami memutuskan bahwa itu sudah cukup untuk menanggungnya. Sudah waktunya untuk memberikan beberapa rutinitas yang membosankan ke bot. Siapa kalau bukan kita? Kapan, jika tidak sekarang?

Apa yang berhasil kami lakukan secara otomatis

Keputusan telah dibuat, saatnya untuk mulai merancang autopilot kami! Setelah menemukan API Kaiten di sini: https://faq.kaiten.io/docs/api , dengan hanya satu permintaan, kami membuat kartu untuk relizmen baru.

//  POST     var createCardRequest = new RestRequest("https://<domain>.kaiten.io/api/latest/cards/", Method.POST); //     AddBasicAuth(createCardRequest); //        -      createCardRequest.AddJsonBody( new { board_id = _kaitenSettings.ReleasesBoardId, column_id = _kaitenSettings.ReleasesColumnId, lane_id = _kaitenSettings.ReleasesLaneId, title = $"release-{nextReleaseNumber}" } ); 

Sekarang kartu ini harus diserahkan kepada tim yang akan merilis kartu berikutnya.

Logikanya di sini adalah:

1. Rilis sebelumnya menyelesaikan rilis dengan mengetikkan perintah untuk bot di Slack.
2. Bot mengambil ID Relisman di Slack dan mencari tim pengembang yang beruntung. Untuk melakukan ini, bot berjalan melalui kelompok-kelompok pengguna Slack dan melihat di mana mereka terdiri dari yang dirilis oleh kami.
3. Setelah menemukan grup, bot melihat tim mana yang akan rilis berikutnya dan mengirimkan peringatan ke obrolan umum. Dalam pesan, bot dengan hati-hati memberikan tautan ke daftar periksa yang sudah dibuat sehingga Anda tidak pergi ke mana pun untuk itu.

Hebat! Sekarang kita memiliki petunjuk apa yang harus dilakukan selanjutnya. Kami membuka daftar periksa, lihat itu: "Buat saluran untuk rilis di Slack, undang semua tim yang perubahannya ada di rilis di sana dan cari tahu apakah mereka akan memerlukan pengujian manual." Masih mengajarkan ini ke bot kami.

Buka dokumentasi Slack API di sini https://api.slack.com dan cari metode untuk membuat saluran di sana.



Seperti yang Anda lihat, di Slack, seperti pada alat lain, tidak ada yang rumit. Itu semua bermuara pada mengirim satu permintaan POST dengan dua parameter yang diperlukan (ini adalah yang berlawanan yang dikatakan diperlukan). Dalam permintaan itu, kita perlu memberikan nama saluran yang dibuat (nama parameter) dan token otorisasi (token parameter). Perhatikan baris "Bekerja dengan: tipe Token - pengguna, cakupan yang diperlukan - saluran: tulis".

Slack memiliki dua jenis token: dikeluarkan pengguna untuk pengguna dan bot dikeluarkan untuk aplikasi. Saat mengeluarkan token, kami menentukan hak apa yang akan diberikan kepada pemiliknya. Untuk membuat saluran, kita memerlukan token pengguna (token type - user), yang memiliki hak untuk menulis saluran (saluran: tulis).

Saya ingin mencatat satu nuansa dari pengiriman pesan kami ke Slack. Awalnya, kami tidak memikirkan apa yang akan kami lakukan jika terjadi kesalahan. Kami merekrut tim di Slack, dan melakukan semua tugas yang kami masukkan ke dalamnya. Dan apa yang akan terjadi jika pada salah satu tugas tim jatuh? Dalam kasus kami, jawabannya adalah: "tidak ada." Dan ini buruk. Solusinya bagi kami adalah menulis dalam rilis obrolan tindakan apa yang saat ini dilakukan, dan jika perintah tidak selesai, laporkan kesalahan ke obrolan dan catat kesalahan tersebut.

Solusi kedua yang berhasil adalah menghubungkan database tempat kami menyimpan status eksekusi dari tindakan perintah. Sekarang, setelah memulai rilis baru menggunakan perintah "/ startregress", kami tidak takut bahwa sesuatu akan jatuh, dan ketika Anda menyebutnya lagi, perintah akan dieksekusi dari awal untuk kedua kalinya. Kami tidak perlu membuat saluran baru di Slack setiap kali, melakukan permintaan tarik, dll. Kami membuat saluran di Slack - kami mencatat status eksekusi yang sukses di database dan tidak akan lagi kembali ke tindakan ini.



Jadi, sekarang dengan mengklik satu tombol kami membuat saluran rilis dan mengundang semua orang di sana yang tugasnya akan dirilis.

Berikutnya adalah integrasi dengan Github dan TeamCity. Kami bekerja di Gitflow. Ketika kami ingin merilis, kami mengambil cabang DEV, yang berfungsi = hijau = di mana tes lulus, dan dari sana kami membuat cabang rilis.

Untuk melakukan ini, bot kami pergi ke TeamCity, terlihat di sana untuk meluncurkan uji coba untuk cabang DEV. Jika tesnya hijau, seperti rumput di dekat rumah, maka lanjutkan ke GitHub, buat cabang rilis dan permintaan tarik!

Saat membuat permintaan tarik, kami perlu menambahkan deskripsi tentang perubahan yang kami lakukan. Lalu Kaiten datang membantu kami. Bot kami membuat kolom dengan nama rilis, mengambil tugas dari kolom DEV dan memindahkannya ke rilis. Jadi kita tahu dan melihat apa yang akan terjadi dengan kita. Setelah bergerak, bot menyalin nama-nama kartu dan menambahkannya ke deskripsi permintaan tarik dengan mengacu pada kartu itu sendiri. Sekarang kita dapat melihat untuk setiap rilis tugas apa yang keluar dan, dengan membuka kartu melalui tautan, cari tahu semua detail pada tugas-tugas ini.



Hampir mungkin untuk dirilis, hanya untuk menguji perubahan kami secara menyeluruh. Untuk melakukan ini, cabang rilis disebarkan ke lingkungan yang dekat dengan produksi (kami menyebutnya tahap), dan diuji setelah rilis. Penempatan dan pengujian dirakit dalam satu pipa di TeamCity, dan tugas kami adalah meluncurkannya dan menunggu, dengan jari-jari, bahwa tes akan bekerja dengan baik. Bot meluncurkan pipa selama dimulainya regresi.

Biarkan saya mengingatkan Anda bahwa kami mulai dengan fakta bahwa semua ini dilakukan secara manual. Sambil mengepalkan tinjunya, Relizmen menyalakan tautan dan alat: TeamCity, Kaiten, Slack, Github dan bukan itu saja! Dan sekarang kami memiliki seluruh rangkaian aksi dari mana tim pertama untuk bot sudah terbentuk. Si pembebas mengetik "/ startregress" dan, bersandar di kursinya, melihat bot kami:

• membuat saluran di messenger
• menelepon ke sana semua orang yang Anda butuhkan
• memeriksa apakah permintaan tarik dapat dibuat
• membuat permintaan tarik dan mengisi uraiannya
• membuat kolom rilis di papan elektronik dan memindahkan kartu tugas di sana
• meluncurkan pipa yang akan melepaskan cabang rilis ke lingkungan dan menjalankan tes di sana

Kami menganalisis seluruh proses rilis, menuliskan berapa banyak waktu yang dibutuhkan setiap tahap rilis. Ini memberikan pengembangan dan bisnis pemahaman tentang waktu yang terbuang dan apa yang menghambat kami dalam memberikan fitur baru kepada pengguna. Kami duduk selama dua hari dan tidak bisa menjalankan tes ?! Jadi ada yang salah dengan tes kami, Anda harus memberi mereka lebih banyak waktu dan perhatian. Sebelumnya, melakukan tindakan daftar periksa kami, kami mengunjungi Google Sheets setidaknya 5 kali. Setiap kali Anda memasukkan satu tanggal di sana dan mengatur waktu.


Oke Google, kami akan mengotomatiskan Anda juga! Untuk bekerja dengan mudah dan mudah dengan tabel, kami menghubungkan paket nuget Google.Apis.Sheets.v4 ke proyek bot kami. Dan kemudian semuanya terjadi dengan cara yang mirip dengan layanan lain sesuai dengan skema: kami mengirim permintaan di mana kami mengatakan apa nilai untuk dimasukkan ke sel mana. Kueri ini terlihat seperti ini:

 public void InsertEntry(string cellAddress, string value) { //          - _googleSettings.SheetName        - cellAddress var range = $"{_googleSettings.SheetName}!{cellAddress}"; var valueRange = new ValueRange(); //        - value var objectsList = new List<object> {$"{value}"}; valueRange.Values = new List<IList<object>> {objectsList}; //    Google.Apis.Sheets.v4           SpreadsheetId var insertEntryRequest = _service.Spreadsheets.Values.Update(valueRange, _googleSettings.SpreadsheetId, range); insertEntryRequest.ValueInputOption = SpreadsheetsResource.ValuesResource.UpdateRequest.ValueInputOptionEnum.USERENTERED; insertEntryRequest.Execute(); } 

Setelah mengatur integrasi dengan Google, kami menyiapkan perintah kedua bot "/ pembaruan" kami dan inilah fungsinya:

• menambahkan string kosong untuk memasukkan nilai ke dalamnya
• pergi ke GitHub, terlihat ketika mereka membuat cabang rilis dan menambahkan tanggal pembuatannya ke tablet
• dari TeamCity mengambil data tentang permulaan pipa pertama dan informasi kapan pipa berhasil diselesaikan

Langkah selanjutnya adalah releaseman memutar rilis. Sekarang perhitungannya dilakukan secara manual. Setelah meletakkan satu negara, kami menyaksikan bagaimana pembebasan berperilaku dalam pertempuran. Setelah memastikan bahwa semuanya baik menurut log dan alat pemantauan Kibana dan Grafana, kami mengirim negara berikutnya. Proses ini tidak mudah untuk diotomatisasi. Tapi di sini ada sesuatu untuk diperbaiki, meskipun tidak dengan bantuan bot. Misalnya, sebelumnya, setiap kali kami bertanya kepada tim infrastruktur apakah mungkin untuk dirilis. Karena ketika kami akan melakukan ini, pekerjaan lain dapat terjadi di server kami dan rilis kami akan datang dengan tidak tepat.

Kami telah mengumpulkan rapat untuk mengoptimalkan proses rilis. Salah satu solusinya adalah bahwa sekarang pemberi kebebasan hanya melihat status di salah satu saluran Slack, di mana infrastruktur mengirimkan izin untuk lepas landas. Ini lebih nyaman daripada terus-menerus menanyakan hal yang sama dan dalam 90% kasus mendapatkan jawaban "Anda bisa."


Untuk beberapa alasan, hal-hal yang tampaknya elementer seperti itu tidak langsung terlintas dalam pikiran. Terima kasih khusus harus disampaikan kepada pengembang baru di perusahaan. Setelah datang kepada kami, cepat atau lambat mereka menjadi relismen. Bagi orang-orang yang bekerja dengan kami untuk waktu yang lama, prosesnya tampaknya bukan sesuatu yang rumit, melainkan sesuatu yang akrab. Anggota tim baru mengalihkan perhatian kami ke poin pertumbuhan dan mengambil bagian aktif dalam mengorganisir pekerjaan untuk perbaikan.

Sementara itu, kita telah sampai pada tahap terakhir. Liner rilis kami telah mendarat, hanya satu tim "/ releasecomplete" yang memisahkan kami dari yang terakhir. Apa yang dia lakukan:

• mergit tarik permintaan dengan rilis ke cabang utama
• menghapus cabang rilis
• membuat deskripsi rilis di github
• arsipkan saluran rilis di Slack
• memindahkan kartu-kartu di Kaiten dari kolom "release -..." ke kolom "Done" dan menghapus kolom rilis
• melewati tongkat, mengundang untuk melepaskan perintah berikutnya

Sebagai rangkuman, saya ingin Anda bertanya pada diri sendiri pertanyaan: apakah Anda memiliki proses rutin yang membosankan? Apakah Anda masih melakukannya dengan tangan Anda? Apa yang mencegah Anda mengakhiri ini sekali dan untuk semua? Kumpulkan rapat, tinjau proses, buang semua yang tidak Anda butuhkan dan itu hanya menjadi ritual. Dengan mengotomatiskan semua yang Anda butuhkan, Anda akan mulai mendapatkan kesenangan dari apa yang sakit sebelumnya, dan menabung hingga tumpukan dengan mempercepat rilis atau proses lainnya.