Mari kita bahas mengapa alat CI dan CI adalah hal yang sangat berbeda.
Masalah apa yang ingin dipecahkan oleh CI, dari mana idenya berasal, konfirmasi terbaru apa yang berhasil, bagaimana memahami bahwa Anda memiliki praktik dan bukan hanya menginstal Jenkins.
Ide membuat laporan tentang Continuous Integration muncul setahun yang lalu, ketika saya akan wawancara dan mencari pekerjaan. Saya berbicara dengan 10-15 perusahaan, hanya satu dari mereka yang mampu menjawab dengan jelas apa itu CI dan menjelaskan bagaimana mereka menyadari bahwa mereka tidak memilikinya. Sisanya membicarakan omong kosong yang tidak dapat dipahami tentang Jenkins :) Ya, kami punya Jenkins, ia memang bisa dibangun, CI! Dalam laporan ini, saya akan mencoba menjelaskan apa sebenarnya Integrasi Berkelanjutan dan mengapa Jenkins dan alat serupa memiliki hubungan yang sangat lemah dengan hal ini.
Lantas, apa yang biasanya terlintas di benak Anda saat mendengar kata CI? Kebanyakan orang akan memikirkan Jenkins, Gitlab CI, Travis, dll.
Bahkan jika kita mencarinya di Google, ia akan memberi kita alat-alat ini.
Jika Anda terbiasa bertanya, maka segera setelah membuat daftar alat, mereka akan memberi tahu Anda bahwa CI adalah saat Anda membuat dan menjalankan pengujian dalam Permintaan Tarik untuk sebuah komit.
Integrasi Berkelanjutan bukan tentang alat, bukan tentang rakitan dengan pengujian di cabang! Integrasi Berkelanjutan adalah praktik integrasi kode baru yang sangat sering dan untuk menggunakannya sama sekali tidak perlu memagari Jenkins, GitLab, dll.
Sebelum kita mengetahui seperti apa CI yang lengkap, pertama-tama mari kita selami konteks orang-orang yang menciptakannya dan rasakan penderitaan yang mereka coba selesaikan.
Dan mereka mengatasi kesulitan bekerja sama sebagai sebuah tim!
Mari kita lihat contoh kesulitan yang dihadapi pengembang saat melakukan pengembangan dalam tim. Di sini kita memiliki sebuah proyek, cabang master di git dan dua pengembang.
Dan mereka mulai bekerja seperti yang sudah biasa dilakukan semua orang. Kami mengambil tugas dalam skema besar, membuat cabang fitur, dan menulis kode.
Seseorang menyelesaikan fitur tersebut lebih cepat dan menggabungkannya ke dalam master.
Yang kedua membutuhkan waktu lebih lama, kemudian menyatu dan berakhir dengan konflik. Kini, alih-alih menulis fitur yang dibutuhkan bisnis, pengembang menghabiskan waktu dan energinya untuk menyelesaikan konflik.
Semakin sulit menggabungkan fitur Anda dengan master umum, semakin banyak waktu yang kami habiskan untuk itu. Dan saya menunjukkannya dengan contoh yang cukup sederhana. Ini adalah contoh dimana hanya ada 2 developer. Bayangkan jika 10 atau 15 atau 100 orang dalam satu perusahaan menulis ke satu repositori. Anda akan menjadi gila untuk menyelesaikan semua konflik ini.
Ada kasus yang sedikit berbeda. Kami memiliki master dan beberapa pengembang yang melakukan sesuatu.
Mereka menciptakan ranting.
Satu meninggal, semuanya baik-baik saja, dia lulus tugas.
Sedangkan pengembang kedua menyerahkan tugasnya. Katakanlah dia mengirimkannya untuk ditinjau. Banyak perusahaan memiliki praktik yang disebut review. Di satu sisi, amalan ini baik dan bermanfaat, di sisi lain, memperlambat kita dalam banyak hal. Kami tidak akan membahasnya, tapi inilah contoh bagus tentang dampak dari cerita ulasan yang buruk. Anda telah mengirimkan permintaan penarikan untuk ditinjau. Tidak ada lagi yang bisa dilakukan pengembang. Apa yang mulai dia lakukan? Dia mulai mengambil tugas lain.
Selama ini, pengembang kedua melakukan hal lain.
Yang pertama menyelesaikan tugas ketiga.
Dan setelah beberapa lama, ulasannya diuji, dan dia mencoba untuk berdamai. Jadi apa yang terjadi? Ini menangkap sejumlah besar konflik. Mengapa? Karena saat permintaan penarikannya ditangguhkan di ulasan, banyak hal yang telah berubah dalam kode.
Selain cerita yang mengandung konflik, ada juga cerita yang mengandung komunikasi. Saat utas Anda sedang ditinjau, menunggu sesuatu, saat Anda mengerjakan suatu fitur untuk waktu yang lama, Anda berhenti melacak apa lagi yang berubah dalam basis kode layanan Anda. Mungkin apa yang Anda coba selesaikan sekarang telah diselesaikan kemarin dan Anda dapat mengambil beberapa metode dan menggunakannya kembali. Namun Anda tidak akan melihat ini karena Anda selalu bekerja dengan cabang yang sudah ketinggalan zaman. Dan cabang yang ketinggalan jaman ini selalu mengakibatkan Anda harus menyelesaikan konflik penggabungan.
Ternyata jika kita bekerja sebagai sebuah tim, yaitu tidak hanya satu orang yang mengaduk-aduk repositori, tetapi 5-10 orang, maka semakin lama kita tidak menambahkan kode kita ke master, semakin kita menderita karena pada akhirnya kita membutuhkannya. sesuatu lalu gabungkan. Dan semakin banyak konflik yang kami hadapi, dan semakin lama versi yang kami gunakan, semakin banyak masalah yang kami hadapi.
Melakukan sesuatu bersama-sama itu menyakitkan! Kami selalu menghalangi satu sama lain.
Masalah ini diketahui lebih dari 20 tahun yang lalu. Saya menemukan penyebutan pertama tentang praktik Integrasi Berkelanjutan dalam Pemrograman Ekstrim.
Pemrograman Ekstrim adalah kerangka tangkas pertama. Halaman tersebut muncul pada tahun 96. Dan idenya adalah menggunakan beberapa praktik pemrograman, perencanaan, dan hal-hal lain agar pengembangannya sefleksibel mungkin sehingga kami dapat dengan cepat merespons setiap perubahan atau persyaratan dari klien kami. Dan mereka mulai menghadapi hal ini 24 tahun yang lalu, bahwa jika Anda melakukan sesuatu untuk waktu yang sangat lama dan di sela-sela, maka Anda menghabiskan lebih banyak waktu untuk itu karena Anda memiliki konflik.
Sekarang kita akan menganalisis frase “Integrasi Berkelanjutan” satu per satu. Jika kita menerjemahkannya secara langsung, kita mendapatkan integrasi berkelanjutan. Namun seberapa berkelanjutannya hal ini tidak terlalu jelas; hal ini sangat terputus-putus. Namun seberapa besar integrasi yang dimilikinya juga tidak terlalu jelas.
Dan itulah mengapa saya memberi Anda kutipan dari Extreme Programming sekarang. Dan kami akan menganalisis kedua kata tersebut secara terpisah.
Integrasi - Seperti yang telah saya katakan, kami berusaha untuk memastikan bahwa setiap insinyur bekerja dengan versi kode terbaru, sehingga ia berusaha untuk menambahkan kodenya sesering mungkin ke cabang umum, sehingga ini adalah cabang kecil. Karena jika besar, maka kita bisa dengan mudah terjebak konflik penggabungan selama seminggu. Hal ini terutama berlaku jika kita memiliki siklus pengembangan yang panjang seperti air terjun, di mana pengembang pergi selama sebulan untuk menghilangkan beberapa fitur besar. Dan dia akan terjebak pada tahap integrasi untuk waktu yang sangat lama.
Integrasi adalah ketika kita mengambil cabang kita dan mengintegrasikannya dengan master, kita menggabungkannya. Ada pilihan terakhir ketika kita adalah pengembang transbase, di mana kita berusaha untuk memastikan bahwa kita segera menulis ke master tanpa cabang tambahan.
Secara umum, integrasi berarti mengambil kode Anda dan menyeretnya ke master.
Yang dimaksud dengan kata “kontinu” di sini, apa yang disebut dengan kontinuitas? Praktek menyiratkan bahwa pengembang berusaha untuk mengintegrasikan kodenya secepat mungkin. Ini adalah tujuannya saat melakukan tugas apa pun - memasukkan kodenya ke master secepat mungkin. Idealnya, pengembang akan melakukan ini setiap beberapa jam. Artinya, Anda mengambil masalah kecil dan menggabungkannya ke dalam master. Semuanya bagus. Inilah yang Anda perjuangkan. Dan hal ini harus dilakukan secara terus menerus. Segera setelah Anda melakukan sesuatu, Anda segera memasukkannya ke dalam master.
Dan pengembang yang membuat sesuatu bertanggung jawab atas apa yang dia lakukan agar itu berfungsi dan tidak merusak apa pun. Di sinilah cerita ujian biasanya muncul. Kami ingin menjalankan beberapa pengujian pada komit kami, pada penggabungan kami, untuk memastikan bahwa itu berfungsi. Dan di sinilah Jenkins dapat membantu Anda.
Tetapi dengan cerita: mari kita buat perubahannya kecil, biarkan tugasnya menjadi kecil, mari kita buat masalah dan segera coba tanamkan ke dalam master - tidak ada Jenkins yang akan membantu di sini. Karena Jenkins hanya akan membantu Anda menjalankan tes.
Anda dapat melakukannya tanpa mereka. Ini tidak akan merugikanmu sama sekali. Karena tujuan latihannya adalah melakukan pengukuran sesering mungkin, agar tidak membuang banyak waktu untuk konflik apa pun di kemudian hari.
Mari kita bayangkan karena suatu alasan kita berada di tahun 2020 tanpa Internet. Dan kami bekerja secara lokal. Kami tidak punya Jenkins. Ini baik-baik saja. Anda masih dapat melanjutkan dan membuat cabang lokal. Anda menulis beberapa kode di dalamnya. Kami menyelesaikan tugas dalam 3-4 jam. Kami beralih ke master, melakukan git pull, dan menggabungkan cabang kami di sana. Siap. Jika Anda sering melakukan ini, selamat, Anda memiliki Integrasi Berkelanjutan!
Bukti apa di dunia modern yang menunjukkan bahwa energi layak untuk dibelanjakan? Karena secara umum sulit. Jika Anda mencoba bekerja seperti ini, Anda akan memahami bahwa beberapa perencanaan sekarang akan terpengaruh, Anda harus mencurahkan lebih banyak waktu untuk menguraikan tugas. Karena jika kamu melakukannya kawan..., maka kamu tidak akan bisa berdamai dengan cepat dan, karenanya, akan mendapat masalah. Anda tidak akan lagi berlatih.
Dan itu akan mahal. Tidak mungkin untuk langsung bekerja mulai besok menggunakan Integrasi Berkelanjutan. Butuh waktu lama bagi Anda semua untuk membiasakannya, butuh waktu lama bagi Anda untuk membiasakan diri menguraikan tugas, butuh waktu sangat lama untuk membiasakan diri mengulangi latihan review, jika ada. . Karena tujuan kami adalah mencairkannya hari ini. Dan jika Anda melakukan peninjauan dalam waktu tiga hari, Anda mengalami masalah dan Integrasi Berkelanjutan tidak berfungsi untuk Anda.
Namun apakah saat ini kita memiliki bukti relevan yang memberi tahu kita bahwa berinvestasi dalam praktik ini masuk akal?
Hal pertama yang terlintas di benak saya adalah State of DevOps. Ini adalah penelitian yang telah dilakukan mereka selama 7 tahun. Sekarang mereka melakukannya sebagai organisasi independen, namun di bawah Google.
Dan studi mereka pada tahun 2018 menunjukkan adanya korelasi antara perusahaan yang mencoba menggunakan cabang berumur pendek yang berintegrasi dengan cepat, sering berintegrasi, dan memiliki indikator kinerja TI yang lebih baik.
Apa saja indikator-indikator tersebut? Ini adalah 4 metrik yang mereka ambil dari semua perusahaan dalam kuesioner mereka: frekuensi penerapan, waktu tunggu untuk perubahan, waktu untuk memulihkan layanan, tingkat kegagalan perubahan.
Dan, pertama, ada korelasi ini, kita tahu bahwa perusahaan yang sering melakukan pengukuran memiliki metrik yang jauh lebih baik. Dan mereka membagi perusahaan menjadi beberapa kategori: perusahaan lambat yang memproduksi sesuatu dengan lambat, perusahaan berkinerja menengah, berkinerja tinggi, dan elit. Elitnya adalah Netflix, Amazon, yang super cepat, melakukan segalanya dengan cepat, indah, dan efisien.
Kisah kedua, yang terjadi sebulan yang lalu. Technology Radar memiliki artikel bagus tentang Gitflow. Gitflow berbeda dari yang lain karena cabangnya berumur panjang. Ada cabang rilis yang berumur panjang, dan cabang unggulan yang juga berumur panjang. Praktik di Technology Radar ini telah dipindahkan ke HOLD. Mengapa? Karena orang-orang menghadapi penderitaan integrasi.
Jika cabang Anda berumur sangat panjang, cabang tersebut akan macet, busuk, dan kita mulai menghabiskan lebih banyak waktu untuk mencoba membuat perubahan pada cabang tersebut.
Dan baru-baru ini penulis Gitflow mengatakan bahwa jika tujuan Anda adalah Integrasi Berkelanjutan, jika tujuan Anda adalah ingin melakukan roll sesering mungkin, maka Gitflow adalah ide yang buruk. Dia secara terpisah menambahkan ke artikel bahwa jika Anda memiliki backend di mana Anda dapat mengupayakannya, maka Gitflow tidak berguna untuk Anda, karena Gitflow akan memperlambat Anda, Gitflow akan menimbulkan masalah bagi Anda dengan integrasi.
Ini tidak berarti Gitflow buruk dan tidak boleh digunakan. Ini untuk kesempatan lain. Misalnya, ketika Anda perlu mendukung beberapa versi suatu layanan atau aplikasi, yaitu ketika Anda memerlukan dukungan untuk jangka waktu yang lama.
Tetapi jika Anda berbicara dengan orang-orang yang mendukung layanan tersebut, Anda akan mendengar banyak kepedihan tentang fakta bahwa versi ini adalah 3.2, yaitu 4 bulan yang lalu, tetapi perbaikan ini tidak disertakan di dalamnya dan sekarang, untuk membuatnya, Anda perlu membuat banyak perubahan. Dan sekarang mereka terjebak lagi, dan sekarang mereka telah mengutak-atik selama seminggu mencoba menerapkan beberapa fitur baru.
Seperti yang dicatat dengan benar oleh Alexander Kovalev dalam obrolan, korelasi tidak sama dengan sebab-akibat. Ini benar. Artinya, tidak ada hubungan langsung bahwa jika Anda memiliki Integrasi Berkelanjutan, maka semua metriknya akan bagus. Namun ada korelasi positif bahwa jika yang satu adalah salah satunya, maka kemungkinan besar yang lainnya juga demikian. Bukan fakta, tapi kemungkinan besar. Itu hanya korelasi.
Sepertinya kita sudah melakukan sesuatu, sepertinya kita sudah bergabung, tapi bagaimana kita bisa memahami bahwa kita masih memiliki Integrasi Berkelanjutan, yang cukup sering kita gabung?
Jez Humble adalah penulis Handbook, Accelerate, situs web Continuous Delivery, dan buku Continuous Delivery. Dia menawarkan tes ini:
- Kode insinyur sampai ke master setiap hari.
- Untuk setiap komit, Anda menjalankan pengujian unit.
- Bangunan di master jatuh, diperbaiki dalam waktu sekitar 10 menit.
Dia menyarankan menggunakan tes seperti ini untuk memastikan Anda memiliki cukup latihan.
Menurut saya yang terakhir ini agak kontroversial. Artinya, jika Anda dapat memperbaikinya dalam 10 menit, maka Anda memiliki Integrasi Berkelanjutan, menurut saya kedengarannya agak aneh, tetapi masuk akal. Mengapa? Karena kalau sering freeze berarti perubahannya kecil. Jika perubahan kecil berarti build master Anda rusak, maka Anda dapat menemukan contohnya dengan cepat karena perubahannya kecil. Di sini Anda memiliki gabungan kecil, 20-30 baris di dalamnya berubah. Dan karenanya, Anda dapat dengan cepat memahami alasannya, karena perubahannya kecil, Anda memiliki area yang sangat kecil untuk mencari masalahnya.
Dan bahkan jika produk kami berantakan setelah dirilis, jika kami mempraktikkan Integrasi Berkelanjutan, akan lebih mudah bagi kami untuk bertindak, karena perubahannya kecil. Ya, ini akan mempengaruhi perencanaan. Ini akan menyakitkan. Dan mungkin hal yang paling sulit dalam latihan ini adalah membiasakan diri membagi tugas, yaitu bagaimana melakukannya sehingga Anda dapat mengambil sesuatu dan menyelesaikannya dalam beberapa jam dan sekaligus lulus review, jika kamu memiliki satu. Ulasan adalah penderitaan tersendiri.
Pengujian unit hanyalah asisten yang membantu Anda memahami apakah integrasi Anda berhasil dan apakah tidak ada yang rusak. Menurut saya, hal ini juga tidak sepenuhnya wajib, karena bukan itu inti praktiknya.
Ini adalah pengenalan singkat tentang Integrasi Berkelanjutan. Hanya itu saja yang ada dalam latihan ini. Saya siap untuk pertanyaan.
Saya akan merangkumnya kembali secara singkat:
- Integrasi Berkelanjutan bukanlah Jenkins, bukan Gitlab.
- Ini bukan alat, ini adalah praktik yang kami lakukan untuk menggabungkan kode kami ke dalam master sesering mungkin.
- Hal ini kita lakukan untuk menghindari rasa sakit luar biasa yang timbul akibat penggabungan di masa depan, yaitu kita mengalami sedikit rasa sakit sekarang agar tidak mengalami lebih banyak rasa sakit di masa depan. Itulah intinya.
- Di sisi lain ada komunikasi melalui kode, tetapi saya sangat jarang melihatnya, tetapi untuk itulah ia dirancang.
pertanyaan
Apa yang harus dilakukan dengan tugas yang tidak terurai?
Membusuk. Apa masalahnya? Bisakah Anda memberi contoh bahwa ada tugas dan tidak terurai?
Ada tugas-tugas yang tidak dapat diuraikan dari kata “sepenuhnya”, misalnya tugas-tugas yang memerlukan keahlian yang sangat mendalam dan sebenarnya dapat diselesaikan dalam waktu sebulan untuk mencapai hasil yang dapat dicerna.
Jika saya memahami Anda dengan benar, maka ada tugas besar dan kompleks, yang hasilnya hanya akan terlihat dalam sebulan?
Ya itu betul. Ya, hasilnya bisa dievaluasi paling cepat dalam sebulan.
Bagus. Secara umum hal ini tidak menjadi masalah. Mengapa? Karena dalam hal ini, jika kita berbicara tentang ranting, yang kita maksud bukanlah ranting yang mempunyai ciri. Fitur bisa berukuran besar dan kompleks. Mereka dapat mempengaruhi sejumlah besar komponen. Dan mungkin kita tidak bisa melakukannya sepenuhnya di satu cabang. Ini baik-baik saja. Kita hanya perlu memecah cerita ini. Jika suatu fitur belum sepenuhnya siap, bukan berarti beberapa bagian kodenya tidak dapat digabungkan. Anda menambahkan, katakanlah, migrasi dan ada beberapa tahapan di dalam fitur tersebut. Katakanlah Anda memiliki tahapan - lakukan migrasi, tambahkan metode baru. Dan Anda sudah bisa mengukur hal-hal ini setiap hari.
Bagus. Lalu apa gunanya?
Apa gunanya membunuh hal-hal kecil setiap hari?
Ya.
Jika mereka merusak sesuatu, Anda akan langsung melihatnya. Anda memiliki bagian kecil yang merusak sesuatu, lebih mudah bagi Anda untuk memperbaikinya. Intinya adalah menggabungkan bagian kecil sekarang jauh lebih mudah daripada menggabungkan sesuatu yang besar dalam beberapa minggu. Dan poin ketiga adalah teknisi lain akan bekerja dengan versi kode saat ini. Mereka akan melihat bahwa beberapa migrasi telah ditambahkan di sini, dan kemudian muncul beberapa metode yang mungkin juga ingin mereka gunakan. Semua orang akan melihat apa yang terjadi pada kode Anda. Untuk ketiga hal inilah latihan dilakukan.
Terima kasih, masalahnya sudah selesai!
(Oleg Soroka) Bolehkah saya menambahkan? Anda mengatakan semuanya dengan benar, saya hanya ingin menambahkan satu kalimat.
Так.
Dengan Integrasi Berkelanjutan, kode digabungkan ke dalam cabang umum bukan saat fitur sudah benar-benar siap, tetapi saat build berhenti rusak. Dan Anda dapat dengan aman berkomitmen untuk menguasai sebanyak yang Anda inginkan dalam sehari. Aspek kedua adalah jika karena alasan tertentu Anda tidak dapat membagi tugas bulanan menjadi tugas selama setidaknya tiga hari, saya diam selama sekitar tiga jam, maka Anda memiliki masalah besar. Dan fakta bahwa Anda tidak memiliki Integrasi Berkelanjutan adalah masalah yang paling kecil. Ini berarti Anda memiliki masalah dengan arsitektur dan tidak ada praktik rekayasa. Karena kalaupun itu penelitian, maka bagaimanapun juga harus dirumuskan dalam bentuk hipotesis atau siklus.
Kita membahas tentang 4 metrik yang membedakan perusahaan sukses dan perusahaan tertinggal. Kita masih harus hidup untuk melihat 4 metrik ini. Jika rata-rata tugas Anda membutuhkan waktu satu bulan untuk diselesaikan, maka saya akan fokus pada metrik ini terlebih dahulu. Saya akan menurunkannya menjadi 3 hari dulu. Dan setelah itu saya mulai memikirkan tentang Continuous.
Apakah saya memahami Anda dengan benar sehingga menurut Anda secara umum tidak ada gunanya berinvestasi dalam praktik teknik jika ada tugas yang membutuhkan waktu satu bulan untuk diselesaikan?
Anda memiliki Integrasi Berkelanjutan. Dan ada topik sedemikian rupa sehingga dalam 10 menit Anda dapat memperbaiki atau membatalkannya. Bayangkan Anda meluncurkannya. Selain itu, Anda bahkan memiliki penerapan berkelanjutan, Anda meluncurkannya ke prod dan baru kemudian menyadari ada yang tidak beres. Dan Anda perlu memutarnya kembali, tetapi Anda telah memigrasikan database Anda. Anda sudah memiliki skema database versi berikutnya, apalagi Anda juga memiliki semacam cadangan, dan data juga ditulis di sana.
Dan alternatif apa yang Anda punya? Jika Anda mengembalikan kode tersebut, maka kode tersebut tidak dapat lagi berfungsi dengan database yang diperbarui ini.
Pangkalannya hanya bergerak maju saja ya.
Orang-orang yang memiliki praktik teknik yang buruk kemungkinan besar belum membaca buku tebal tentang... juga. Apa yang harus dilakukan dengan cadangannya? Jika Anda memulihkan dari cadangan, itu berarti Anda kehilangan data yang telah Anda kumpulkan pada saat itu. Misalnya, kami bekerja selama tiga jam dengan database versi baru, pengguna terdaftar di sana. Anda menolak pencadangan lama karena skema tidak berfungsi dengan versi baru, sehingga Anda kehilangan pengguna tersebut. Dan mereka tidak puas, mereka bersumpah.
Untuk menguasai seluruh praktik yang mendukung Integrasi Berkelanjutan dan Pengiriman Berkelanjutan, tidak cukup hanya belajar menulis.... Pertama, jumlahnya bisa banyak, itu tidak praktis. Ditambah lagi, ada banyak praktik lain seperti Scientific. Ada praktik seperti itu, GitHub pernah mempopulerkannya. Ini adalah saat Anda menjalankan kode lama dan kode baru secara bersamaan. Ini adalah saat Anda membuat fitur yang belum selesai, namun dapat mengembalikan beberapa nilai: baik sebagai fungsi atau sebagai Rest API. Anda menjalankan kode baru dan kode lama, dan membandingkan perbedaan di antara keduanya. Dan jika ada perbedaan, maka Anda mencatat peristiwa ini. Dengan cara ini Anda mengetahui bahwa Anda memiliki fitur baru yang siap diluncurkan di atas fitur lama jika Anda tidak mengalami perbedaan di antara keduanya selama waktu tertentu.
Ada ratusan praktik seperti itu. Saya menyarankan memulai dengan pengembangan transbase. Dia tidak 100% melakukan Integrasi Berkelanjutan, tetapi praktiknya sama, yang satu tidak bisa hidup dengan baik tanpa yang lain.
Apakah Anda memberikan pengembangan transbase sebagai contoh di mana Anda dapat melihat praktiknya atau apakah Anda menyarankan orang-orang untuk mulai menggunakan pengembangan transbase?
Coba lihat, karena mereka tidak akan bisa menggunakannya. Untuk menggunakannya, Anda perlu banyak membaca. Dan ketika seseorang bertanya: “Apa yang harus dilakukan dengan fitur yang membutuhkan waktu sebulan, itu berarti dia belum membaca tentang pengembangan transbase.” Saya belum akan merekomendasikannya. Saya akan menyarankan untuk fokus hanya pada topik tentang bagaimana memecah tugas-tugas besar menjadi tugas-tugas yang lebih kecil secara arsitektural. Inilah inti dari dekomposisi.
Dekomposisi adalah salah satu alat arsitek. Pertama-tama kita melakukan analisis, lalu dekomposisi, lalu sintesis, lalu integrasi. Dan beginilah semuanya berjalan baik bagi kami. Dan kita masih perlu berkembang menuju Integrasi Berkelanjutan melalui dekomposisi. Pertanyaan muncul pada tahap pertama, dan kita sudah membicarakan tahap keempat, yaitu semakin sering kita melakukan integrasi, semakin baik. Masih terlalu dini untuk melakukan ini; alangkah baiknya jika monolit Anda ditebang terlebih dahulu.
Anda perlu menggambar sejumlah panah dan kotak pada beberapa diagram. Anda tidak bisa mengatakan bahwa sekarang saya akan menunjukkan diagram arsitektur aplikasi baru dan menunjukkan satu kotak, di dalamnya terdapat tombol hijau untuk aplikasi tersebut. Bagaimanapun, akan ada lebih banyak kotak dan panah. Setiap diagram yang saya lihat memiliki lebih dari satu. Dan dekomposisi, bahkan pada tingkat representasi grafis, sudah berlangsung. Oleh karena itu, bujur sangkar dapat dibuat mandiri. Jika tidak, maka saya punya pertanyaan besar untuk arsiteknya.
Ada pertanyaan dari chat tersebut: “Kalau review wajib dan memakan waktu lama, mungkin sehari atau lebih?”
Anda memiliki masalah dengan latihan. Peninjauan tidak boleh berlangsung sehari atau lebih. Ini cerita yang sama dengan pertanyaan sebelumnya, hanya saja sedikit lebih lembut. Jika peninjauan berlangsung selama sehari, kemungkinan besar peninjauan ini akan mengalami perubahan yang sangat besar. Artinya perlu dibuat lebih kecil. Dalam pengembangan transbase yang direkomendasikan Oleg, ada sebuah cerita yang disebut tinjauan berkelanjutan. Idenya adalah kami membuat permintaan tarik kecil dengan sengaja, karena kami berusaha untuk menggabungkan secara terus-menerus dan sedikit demi sedikit. Jadi permintaan tarik mengubah satu abstraksi atau 10 baris. Berkat ulasan ini, kami memerlukan waktu beberapa menit.
Jika peninjauan memakan waktu satu hari atau lebih, berarti ada yang salah. Pertama, Anda mungkin mengalami beberapa masalah dengan arsitektur. Atau ini adalah potongan kode yang besar, 1 baris, misalnya. Atau arsitektur Anda begitu rumit sehingga seseorang tidak dapat memahaminya. Ini adalah masalah yang agak menyimpang, tetapi juga harus diselesaikan. Mungkin tidak perlu ada review sama sekali. Hal ini juga perlu kita pikirkan. Ulasan adalah hal yang memperlambat Anda. Secara umum, ini memiliki kelebihan, tetapi Anda perlu memahami mengapa Anda melakukannya. Apakah ini cara Anda menyampaikan informasi dengan cepat, apakah ini cara Anda menetapkan standar tertentu secara internal atau bagaimana? Mengapa Anda membutuhkan ini? Karena peninjauan perlu dilakukan dengan sangat cepat atau dibatalkan sama sekali. Ini seperti pengembangan transbase - ceritanya sangat indah, tetapi hanya untuk pria dewasa.
Mengenai 4 metrik, saya tetap menyarankan untuk menghapusnya untuk memahami akibatnya. Lihat angkanya, lihat gambarnya, betapa buruknya semuanya.
(Dmitry) Saya siap berdiskusi dengan Anda tentang hal ini. Angka dan metriknya bagus, praktiknya bagus. Namun Anda perlu memahami apakah bisnis membutuhkannya. Ada bisnis yang tidak membutuhkan kecepatan perubahan seperti itu. Saya tahu perusahaan yang perubahannya tidak bisa dilakukan setiap 15 menit. Dan bukan karena mereka begitu buruk. Ini adalah siklus hidup. Dan untuk menjadikan fitur cabang, fitur sakelar, diperlukan pengetahuan yang mendalam.
Ini rumit. Jika Anda ingin membaca cerita tentang fitur togel lebih detail, saya sangat merekomendasikannya . Dan ada artikel bagus dari Martin Fowler tentang fitur sakelar: jenis apa yang ada, siklus hidup, dll. Fitur sakelar itu rumit.
Dan Anda masih belum menjawab pertanyaan: “Apakah Jenkins dibutuhkan atau tidak?”
Jenkins sebenarnya tidak diperlukan dalam hal apa pun. Namun serius, alatnya: Jenkins, Gitlab akan memberi Anda kenyamanan. Anda akan melihat bahwa rakitan sudah dirakit atau belum dirakit. Mereka bisa membantu Anda, tapi mereka tidak akan memberi Anda latihan. Mereka hanya bisa memberi Anda lingkaran - Oke, bukan Oke. Dan kemudian, jika Anda juga menulis tes, karena jika tidak ada tes, maka hampir tidak ada gunanya. Oleh karena itu diperlukan karena lebih nyaman, namun secara umum Anda bisa hidup tanpanya, tidak akan rugi banyak.
Artinya, jika Anda punya amalan, apakah berarti Anda tidak membutuhkannya?
Itu benar. Saya merekomendasikan tes Jez Humble. Di sana saya memiliki sikap ambivalen terhadap poin terakhir. Namun secara umum, jika Anda memiliki tiga hal, Anda terus-menerus menggabungkannya, Anda menjalankan tes pada penerapan di master, Anda dengan cepat memperbaiki build di master, maka mungkin Anda tidak memerlukan yang lain.
Sambil menunggu pertanyaan dari peserta, saya punya pertanyaan. Kami baru saja berbicara tentang kode produk. Sudahkah Anda menggunakannya untuk kode infrastruktur? Apakah kodenya sama, apakah memiliki prinsip dan siklus hidup yang sama, ataukah terdapat siklus hidup dan prinsip yang berbeda? Biasanya, ketika semua orang berbicara tentang Integrasi dan Pembangunan Berkelanjutan, semua orang lupa bahwa ada juga kode infrastruktur. Dan belakangan ini jumlahnya semakin banyak. Dan haruskah semua peraturan ini diterapkan di sana?
Bahkan tidak seharusnya demikian, itu akan bagus karena akan membuat hidup lebih mudah dengan cara yang sama. Segera setelah kami bekerja dengan kode, bukan dengan skrip bash, tetapi kami memiliki kode normal.
Berhenti, hentikan, skrip bash juga merupakan kode. Jangan sentuh cinta lamaku.
Oke, aku tidak akan menginjak-injak kenanganmu. Saya pribadi tidak menyukai pesta. Itu jelek dan menakutkan sepanjang waktu. Dan sering kali rusak secara tidak terduga, itulah sebabnya saya tidak menyukainya. Tapi oke, katakanlah Anda memiliki kode bash. Mungkin saya benar-benar tidak mengerti dan ada kerangka pengujian normal di luar sana. Aku hanya tidak mengetahuinya. Dan kita mendapatkan manfaat yang sama.
Segera setelah kami bekerja dengan infrastruktur sebagai kode, kami mendapatkan semua masalah yang sama seperti pengembang. Beberapa bulan yang lalu, saya menghadapi situasi di mana seorang kolega mengirimi saya permintaan penarikan 1 baris di bash. Dan Anda nongkrong di review selama 000 jam. Masalah yang sama juga muncul. Itu masih kode. Dan itu masih kolaborasi. Kami terjebak dengan permintaan penarikan dan terjebak dengan fakta bahwa kami menyelesaikan konflik penggabungan yang sama di bash yang sama, misalnya.
Saya sekarang sangat aktif melihat semua hal tentang pemrograman infra yang paling indah. Saya sekarang telah membawa Pulumi ke dalam infrastruktur. Ini adalah pemrograman dalam bentuknya yang paling murni. Itu bahkan lebih bagus, karena saya memiliki semua kemampuan bahasa pemrograman, mis. Saya tiba-tiba membuat peralihan yang indah dengan if yang sama dan semuanya baik-baik saja. Artinya, kembalian saya sudah ada di master. Semua orang sudah bisa melihatnya. Insinyur lain mengetahuinya. Itu sudah mempengaruhi sesuatu di sana. Namun, hal ini tidak diaktifkan untuk semua infrastruktur. Ini diaktifkan untuk bangku tes saya, misalnya. Oleh karena itu, untuk menjawab pertanyaan Anda lagi, itu perlu. Ini membuat hidup lebih mudah bagi kami, sebagai insinyur yang bekerja dengan kode, dengan cara yang sama.
Jika ada orang lain yang memiliki pertanyaan?
Saya punya pertanyaan. Saya ingin melanjutkan diskusi dengan Oleg. Secara umum, menurut saya Anda benar, jika suatu tugas membutuhkan waktu satu bulan untuk diselesaikan, maka Anda memiliki masalah dengan arsitektur, Anda memiliki masalah dengan analisis, dekomposisi, perencanaan, dll. Namun saya merasa jika Anda memulai mencoba hidup sesuai Integrasi Berkelanjutan, maka Anda akan mulai memperbaiki rasa sakit dengan perencanaan, karena Anda tidak akan lepas darinya di tempat lain.
(Oleg) Ya itu benar. Upaya praktik ini sebanding dengan praktik perubahan budaya serius lainnya. Hal yang paling sulit diatasi adalah kebiasaan, terutama kebiasaan buruk. Dan jika untuk menerapkan praktik ini diperlukan perubahan serius dalam kebiasaan orang-orang di sekitar Anda: pengembang, manajemen, manajer produksi, maka kejutan menanti Anda.
Kejutan apa yang mungkin terjadi? Katakanlah Anda memutuskan bahwa Anda akan lebih sering berintegrasi. Dan Anda memiliki beberapa hal lain yang terkait dengan integrasi, misalnya artefak. Dan di perusahaan Anda, misalnya, ada kebijakan bahwa setiap artefak harus diperhitungkan dalam beberapa jenis sistem penyimpanan artefak. Dan itu membutuhkan waktu. Seseorang perlu mencentang kotak bahwa dia, sebagai manajer rilis, telah menguji artefak ini untuk memastikan artefak tersebut siap dirilis dalam produksi. Jika dibutuhkan 5-10-15 menit, tetapi Anda melakukan tata letaknya seminggu sekali, maka menghabiskan setengah jam seminggu sekali adalah pajak yang kecil.
Jika Anda melakukan Continuous Integration 10 kali sehari, maka 10 kali tersebut perlu dikalikan 30 menit. Dan ini melebihi jumlah waktu kerja manajer rilis ini. Dia hanya bosan melakukannya. Ada biaya tetap untuk beberapa praktik. Itu saja.
Dan Anda harus membatalkan aturan ini agar Anda tidak lagi melakukan sampah seperti itu, yaitu Anda tidak secara manual menetapkan gelar yang sesuai dengan sesuatu. Anda sepenuhnya mengandalkan beberapa rangkaian tes kesiapan otomatis.
Dan jika Anda memerlukan bukti dari seseorang agar bos menandatanganinya, dan Anda tidak masuk ke produksi tanpa Vasya mengatakan bahwa dia mengizinkannya, dll. - semua omong kosong ini menghalangi praktisi. Karena kalau ada kegiatan yang berhubungan dengan pajak, maka semuanya naik 100 kali lipat. Oleh karena itu, peralihan tersebut seringkali tidak disambut dengan gembira oleh semua orang. Karena kebiasaan masyarakat sulit diubah.
Ketika seseorang melakukan pekerjaannya yang biasa, dia melakukannya hampir tanpa berpikir. Beban kognitifnya nol. Dia hanya bermain-main saja, dia sudah punya checklist di kepalanya, dia sudah melakukannya ribuan kali. Dan segera setelah Anda datang dan memberi tahu dia: “Mari kita batalkan praktik ini dan perkenalkan praktik baru mulai Senin,” baginya ini menjadi beban kognitif yang kuat. Dan itu terjadi pada semua orang sekaligus.
Oleh karena itu, hal yang paling sederhana, walaupun tidak semua orang mampu membeli kemewahan ini, namun inilah yang selalu saya lakukan, berikut ini. Jika sebuah proyek baru dimulai, maka biasanya semua praktik yang belum teruji langsung dijejalkan ke dalam proyek ini. Meskipun proyek ini masih muda, kami tidak mengambil risiko apa pun. Belum ada Prod, belum ada yang perlu dihancurkan. Oleh karena itu, dapat digunakan sebagai pelatihan. Pendekatan ini berhasil. Namun tidak semua perusahaan mempunyai kesempatan untuk sering memulai proyek seperti itu. Meski hal ini juga sedikit aneh, karena kini telah terjadi transformasi digital yang menyeluruh, setiap orang harus melancarkan eksperimen agar bisa bersaing dengan kompetitor.
Di sini Anda sampai pada kesimpulan bahwa Anda harus terlebih dahulu memahami apa yang perlu Anda lakukan. Dunia ini tidak ideal, dan produksi juga tidak ideal.
Ya, hal-hal ini saling berhubungan.
Dunia usaha juga tidak selalu memahami bahwa mereka perlu melakukan hal ini.
Ada situasi di mana tidak ada perubahan yang mungkin terjadi sama sekali. Ini adalah situasi di mana ada lebih banyak tekanan pada tim. Tim sudah cukup kelelahan. Dia tidak punya waktu luang untuk eksperimen apa pun. Mereka mengerjakan fitur dari pagi hingga sore. Dan manajemen memiliki fitur yang semakin sedikit. Dibutuhkan lebih banyak lagi. Dalam situasi seperti ini, tidak ada perubahan yang mungkin terjadi. Tim hanya bisa diberitahu bahwa besok kami akan melakukan hal yang sama seperti kemarin, kami hanya perlu membuat lebih banyak fitur. Dalam hal ini, tidak ada transisi ke praktik apa pun yang mungkin dilakukan. Ini adalah situasi klasik ketika tidak ada waktu untuk mengasah kapak, pohon perlu ditebang, sehingga ditebang dengan kapak yang tumpul. Tidak ada tip sederhana di sini.
(Dmitry) Saya akan membacakan klarifikasi dari obrolan: “Tetapi kami membutuhkan banyak cakupan tes di berbagai level. Berapa banyak waktu yang dialokasikan untuk tes? Ini sedikit mahal dan memakan banyak waktu.”
(Oleg) Ini adalah kesalahpahaman klasik. Harus ada tes yang cukup agar Anda bisa percaya diri. Integrasi Berkelanjutan bukanlah sesuatu yang 100% pengujiannya dilakukan terlebih dahulu dan baru kemudian Anda mulai menerapkan praktik ini. Integrasi Berkelanjutan mengurangi beban kognitif Anda karena setiap perubahan yang Anda lihat dengan mata Anda begitu jelas sehingga Anda memahami apakah itu akan merusak sesuatu atau tidak, bahkan tanpa tes. Anda dapat dengan cepat mengujinya di kepala Anda karena perubahannya kecil. Meskipun Anda hanya memiliki penguji manual, itu juga lebih mudah bagi mereka. Anda meluncurkannya dan berkata: “Lihat, apakah ada yang rusak?” Mereka memeriksa dan berkata, “Tidak, tidak ada yang rusak.” Karena penguji tahu di mana mencarinya. Anda memiliki satu komit yang terkait dengan satu bagian kode. Dan ini dimanfaatkan oleh perilaku tertentu.
Di sini Anda, tentu saja, menghiasi.
(Dmitry) Saya tidak setuju di sini. Ada praktik - pengembangan berbasis pengujian yang akan menyelamatkan Anda dari hal ini.
(Oleg) Ya, saya belum sampai ke titik itu. Ilusi pertama adalah Anda perlu menulis 100% tes atau Anda tidak perlu melakukan Integrasi Berkelanjutan sama sekali. Itu tidak benar. Ini adalah dua praktik paralel. Dan mereka tidak bergantung langsung. Cakupan tes Anda harus optimal. Optimal - ini berarti Anda sendiri yakin bahwa kualitas master yang dimiliki master Anda setelah penerapan memungkinkan Anda dengan percaya diri menekan tombol "Deploy" pada Jumat malam yang mabuk. Bagaimana Anda mencapainya? Melalui review, melalui liputan, melalui monitoring yang baik.
Pemantauan yang baik tidak dapat dibedakan dengan pengujian. Jika Anda menjalankan pengujian sekali pada pra produksi, maka pengujian tersebut akan memeriksa semua skrip pengguna Anda satu kali dan selesai. Dan jika Anda menjalankannya dalam putaran tanpa akhir, maka ini adalah sistem pemantauan Anda yang diterapkan, yang tanpa henti menguji semuanya - apakah macet atau tidak. Dalam hal ini, satu-satunya perbedaan adalah apakah hal itu dilakukan sekali atau dua kali. Serangkaian tes yang sangat bagus... berjalan tanpa henti, ini adalah pemantauan. Dan pemantauan yang tepat harus seperti ini.
Oleh karena itu, bagaimana tepatnya Anda akan mencapai keadaan ini ketika Anda bersiap-siap pada Jumat malam dan pulang adalah pertanyaan lain. Mungkin Anda hanya bajingan yang berani.
Mari kita kembali sedikit ke Integrasi Berkelanjutan. Kami beralih ke praktik kompleks yang sedikit berbeda.
Dan ilusi kedua adalah MVP, kata mereka, perlu dilakukan dengan cepat, sehingga tes tidak diperlukan sama sekali. Tentu saja tidak seperti itu. Faktanya adalah ketika Anda menulis cerita pengguna di MVP, Anda dapat mengembangkannya, yaitu, Anda mendengar bahwa ada semacam cerita pengguna dan segera menjalankan kodenya, atau Anda dapat bekerja menggunakan TDD. Dan menurut TDD, seperti yang ditunjukkan oleh praktik, ini tidak memakan waktu lebih lama, yaitu tes adalah efek samping. Praktek TDD bukan tentang pengujian. Terlepas dari apa yang disebut Test Driven Development, ini sama sekali bukan tentang pengujian. Ini juga merupakan pendekatan arsitektural. Ini adalah pendekatan untuk menulis apa yang dibutuhkan dan bukan menulis apa yang tidak diperlukan. Ini adalah praktik berfokus pada iterasi pemikiran Anda berikutnya dalam hal menciptakan arsitektur aplikasi.
Oleh karena itu, tidak mudah untuk menghilangkan ilusi tersebut. MVP dan tes tidak saling bertentangan. Bahkan sebaliknya, jika Anda melakukan MVP dengan menggunakan latihan TDD, maka Anda akan melakukannya lebih baik dan lebih cepat dibandingkan jika Anda melakukannya tanpa latihan sama sekali, melainkan dengan bola.
Ini adalah gagasan yang sangat tidak jelas dan kompleks. Ketika Anda mendengar bahwa sekarang saya akan menulis lebih banyak tes dan pada saat yang sama saya akan melakukan sesuatu lebih cepat, kedengarannya sama sekali tidak memadai.
(Dmitry) Banyak orang di sini, ketika mereka memanggil MVP, orang terlalu malas untuk menulis sesuatu yang normal. Dan ini masih merupakan hal yang berbeda. Tidak perlu mengubah MVP menjadi hal buruk yang tidak berhasil.
Ya, ya, kamu benar.
Dan tiba-tiba MVP di prod.
Selama-lamanya.
Dan TDD terdengar sangat tidak biasa ketika Anda mendengar bahwa Anda sedang menulis tes dan sepertinya melakukan lebih banyak pekerjaan. Kedengarannya sangat aneh, tetapi ternyata cara ini menjadi lebih cepat dan lebih indah. Saat Anda menulis tes, Anda sudah memikirkan banyak hal tentang kode apa yang akan dipanggil dan bagaimana caranya, serta perilaku apa yang kita harapkan darinya. Anda tidak hanya mengatakan saya menulis beberapa fungsi dan melakukan sesuatu. Tadinya kalian mengira dia mempunyai kondisi ini dan itu, dia akan dipanggil dengan cara ini dan itu. Anda membahasnya dengan tes dan dari sini Anda memahami bagaimana tampilan antarmuka Anda di dalam kode Anda. Hal ini berdampak besar pada arsitektur. Kode Anda secara otomatis menjadi lebih modular, karena Anda terlebih dahulu mencoba memahami bagaimana Anda akan mengujinya, dan baru kemudian menulisnya.
Apa yang terjadi pada saya dengan TDD adalah pada suatu saat saya menyewa seorang mentor Ruby ketika saya masih menjadi programmer Ruby. Dan dia berkata: “Mari kita lakukan sesuai TDD.” Saya berpikir: “Sial, sekarang saya harus menulis sesuatu yang ekstra.” Dan kami sepakat bahwa dalam waktu dua minggu saya akan menulis semua kode kerja dengan Python menggunakan TDD. Setelah dua minggu, saya menyadari bahwa saya tidak ingin kembali. Setelah dua minggu mencoba menerapkan hal ini di mana pun, Anda menyadari betapa lebih mudahnya bagi Anda untuk sekadar berpikir. Tapi ini tidak jelas, jadi saya menyarankan kepada semua orang bahwa jika Anda merasa TDD itu sulit, memakan waktu dan tidak perlu, cobalah bertahan selama dua minggu saja. Dua sudah cukup bagiku.
(Dmitry) Kita dapat memperluas ide ini dari sudut pandang pengoperasian infrastruktur. Sebelum kami meluncurkan sesuatu yang baru, kami melakukan pemantauan dan kemudian meluncurkannya. Dalam hal ini, pemantauan menjadi pengujian biasa bagi kami. Dan ada pengembangan melalui pemantauan. Tapi hampir semua bilang panjang, saya malas, saya buat draft sementara. Jika kita telah melakukan pemantauan secara normal, kita memahami keadaan sistem CI. Dan sistem CI memiliki banyak pemantauan. Kami memahami keadaan sistem, kami memahami apa yang ada di dalamnya. Dan dalam pengembangannya, kami hanya membuat sistem agar mencapai keadaan yang diinginkan.
Praktik-praktik ini sudah dikenal sejak lama. Kami membahas ini sekitar 4 tahun yang lalu. Namun dalam 4 tahun praktis tidak ada yang berubah.
Namun pada catatan ini, saya mengusulkan untuk mengakhiri diskusi resmi.
Video (dimasukkan sebagai elemen media, tetapi karena alasan tertentu tidak berfungsi):
Sumber: www.habr.com