Mari kita bincangkan mengapa alat CI dan CI adalah perkara yang sama sekali berbeza.
Apakah kesakitan yang ingin diselesaikan oleh CI, dari mana idea itu datang, apakah pengesahan terkini bahawa ia berfungsi, bagaimana untuk memahami bahawa anda mempunyai amalan dan bukan hanya memasang Jenkins.
Idea untuk membuat laporan mengenai Integrasi Berterusan muncul setahun yang lalu, semasa saya pergi untuk temu duga dan mencari pekerjaan. Saya bercakap dengan 10-15 syarikat, hanya satu daripada mereka dapat menjawab dengan jelas apa itu CI dan menerangkan bagaimana mereka menyedari bahawa mereka tidak memilikinya. Selebihnya bercakap karut yang tidak dapat difahami tentang Jenkins :) Nah, kami mempunyai Jenkins, ia membina, CI! Semasa laporan itu, saya akan cuba menerangkan apa itu Integrasi Berterusan dan mengapa Jenkins dan alat serupa mempunyai hubungan yang sangat lemah dengan ini.
Jadi, apa yang selalu terlintas di fikiran apabila mendengar perkataan CI? Kebanyakan orang akan memikirkan Jenkins, Gitlab CI, Travis, dll.
Walaupun kita google, ia akan memberikan kita alat ini.
Jika anda sudah biasa bertanya, maka sejurus selepas menyenaraikan alatan, mereka akan memberitahu anda bahawa CI ialah apabila anda membina dan menjalankan ujian dalam Permintaan Tarik untuk komit.
Integrasi Berterusan bukan tentang alat, bukan tentang perhimpunan dengan ujian dalam cawangan! Integrasi Berterusan ialah amalan penyepaduan kod baharu yang sangat kerap dan untuk menggunakannya tidak perlu sama sekali untuk memagar Jenkins, GitLab, dsb.
Sebelum kita mengetahui rupa CI yang lengkap, mari kita menyelami konteks orang yang menciptanya dan merasakan kesakitan yang mereka cuba selesaikan.
Dan mereka menyelesaikan kesakitan bekerja bersama sebagai satu pasukan!
Mari lihat contoh kesukaran yang dihadapi oleh pembangun apabila membangun dalam pasukan. Di sini kami mempunyai projek, cawangan induk dalam git dan dua pemaju.
Dan mereka pergi bekerja kerana semua orang telah lama terbiasa. Kami mengambil tugas dalam skema besar perkara, mencipta cawangan ciri dan menulis kod.
Satu menyelesaikan ciri dengan lebih cepat dan menggabungkannya ke dalam induk.
Yang kedua memerlukan lebih banyak masa, ia bergabung kemudian dan berakhir dengan konflik. Kini, bukannya menulis ciri yang diperlukan oleh perniagaan, pembangun menghabiskan masa dan tenaganya untuk menyelesaikan konflik.
Lebih sukar untuk menggabungkan ciri anda dengan tuan biasa, lebih banyak masa yang kami luangkan untuknya. Dan saya menunjukkan ini dengan contoh yang agak mudah. Ini adalah contoh di mana hanya terdapat 2 pemaju. Bayangkan jika 10 atau 15 atau 100 orang dalam sebuah syarikat menulis kepada satu repositori. Anda akan menjadi gila untuk menyelesaikan semua konflik ini.
Terdapat kes yang sedikit berbeza. Kami mempunyai tuan dan beberapa pembangun melakukan sesuatu.
Mereka mencipta ranting.
Seorang mati, semuanya baik-baik saja, dia lulus tugas.
Pemaju kedua pula menyerahkan tugasnya. Katakan dia menghantarnya untuk semakan. Banyak syarikat mempunyai amalan yang dipanggil semakan. Di satu pihak, amalan ini baik dan berguna, sebaliknya, ia melambatkan kita dalam banyak cara. Kami tidak akan membincangkannya, tetapi berikut ialah contoh yang bagus tentang perkara yang boleh ditimbulkan oleh cerita ulasan yang buruk. Anda telah menyerahkan permintaan tarik untuk semakan. Tiada apa lagi yang perlu dilakukan oleh pembangun. Apa yang dia mula buat? Dia mula mengambil tugas lain.
Pada masa ini, pembangun kedua melakukan sesuatu yang lain.
Yang pertama menyelesaikan tugas ketiga.
Dan selepas beberapa lama, ulasannya telah diuji, dan dia cuba untuk bersetuju. Jadi apa yang berlaku? Ia menangkap sejumlah besar konflik. kenapa? Kerana semasa permintaan tariknya tergantung dalam ulasan, banyak perkara telah berubah dalam kod.
Sebagai tambahan kepada cerita dengan konflik, terdapat cerita dengan komunikasi. Semasa urutan anda tergantung pada ulasan, semasa ia menunggu sesuatu, semasa anda memotong ciri untuk masa yang lama, anda berhenti menjejaki perkara lain yang berubah dalam asas kod perkhidmatan anda. Mungkin perkara yang anda cuba selesaikan sekarang telah pun diselesaikan semalam dan anda boleh mengambil beberapa kaedah dan menggunakannya semula. Tetapi anda tidak akan melihat ini kerana anda sentiasa bekerja dengan cawangan yang sudah lapuk. Dan cawangan lapuk ini sentiasa menyebabkan anda perlu menyelesaikan konflik gabungan.
Ternyata jika kita bekerja sebagai satu pasukan, iaitu, bukan seorang yang mencolok di dalam repositori, tetapi 5-10 orang, maka semakin lama kita tidak menambah kod kita kepada tuan, semakin kita menderita kerana kita akhirnya memerlukan sesuatu kemudian gabungkannya. Dan lebih banyak konflik yang kita ada, dan versi lama yang kita tangani, lebih banyak masalah yang kita hadapi.
Melakukan sesuatu bersama adalah menyakitkan! Kami sentiasa menghalang satu sama lain.
Masalah ini disedari lebih 20 tahun lalu. Saya dapati sebutan pertama tentang amalan Integrasi Berterusan dalam Pengaturcaraan Ekstrem.
Pengaturcaraan Extreme ialah rangka kerja tangkas yang pertama. Halaman itu muncul pada tahun 96. Dan ideanya adalah untuk menggunakan beberapa jenis amalan pengaturcaraan, perancangan dan perkara lain, supaya pembangunan akan menjadi sefleksibel yang mungkin, supaya kami boleh bertindak balas dengan cepat kepada sebarang perubahan atau keperluan daripada pelanggan kami. Dan mereka mula menghadapi perkara ini 24 tahun yang lalu, bahawa jika anda melakukan sesuatu untuk masa yang sangat lama dan di luar, maka anda menghabiskan lebih banyak masa kerana anda mempunyai konflik.
Sekarang kita akan menganalisis frasa "Integrasi Berterusan" secara individu. Jika kita menterjemahkannya secara langsung, kita mendapat penyepaduan berterusan. Tetapi sejauh mana ia berterusan tidak begitu jelas; ia sangat tidak berterusan. Tetapi berapa banyak integrasi yang ada juga tidak begitu jelas.
Dan itulah sebabnya saya memberi anda petikan daripada Extreme Programming sekarang. Dan kami akan menganalisis kedua-dua perkataan secara berasingan.
Penyepaduan - Seperti yang telah saya katakan, kami berusaha untuk memastikan setiap jurutera berfungsi dengan versi kod terkini, supaya dia berusaha untuk menambah kodnya sekerap mungkin ke cawangan biasa, supaya ini adalah cawangan kecil. Kerana jika mereka besar, maka kita boleh dengan mudah terjebak dengan konflik gabungan selama seminggu. Ini benar terutamanya jika kita mempunyai kitaran pembangunan yang panjang seperti air terjun, di mana pembangun pergi selama sebulan untuk memotong beberapa ciri besar. Dan dia akan terperangkap pada peringkat integrasi untuk masa yang sangat lama.
Integrasi ialah apabila kami mengambil cawangan kami dan menyepadukannya dengan induk, kami menggabungkannya. Terdapat pilihan muktamad apabila kami adalah pembangun transbase, di mana kami berusaha untuk memastikan kami segera menulis kepada induk tanpa sebarang cawangan tambahan.
Secara umum, penyepaduan bermakna mengambil kod anda dan menyeretnya ke dalam induk.
Apakah yang dimaksudkan di sini dengan perkataan "berterusan", apakah yang dipanggil kesinambungan? Amalan membayangkan bahawa pembangun berusaha untuk menyepadukan kodnya secepat mungkin. Ini adalah matlamatnya semasa melakukan apa-apa tugas - untuk mendapatkan kodnya muncul dalam induk secepat mungkin. Dalam dunia yang ideal, pembangun akan melakukan ini setiap beberapa jam. Iaitu, anda mengambil masalah kecil dan menggabungkannya menjadi tuan. Semuanya bagus. Inilah yang anda perjuangkan. Dan ini mesti dilakukan secara berterusan. Sebaik sahaja anda melakukan sesuatu, anda segera memasukkannya ke dalam tuan.
Dan pembangun yang membuat sesuatu bertanggungjawab atas apa yang dia lakukan untuk menjadikannya berfungsi dan tidak melanggar apa-apa. Di sinilah biasanya cerita ujian keluar. Kami ingin menjalankan beberapa ujian pada komitmen kami, pada gabungan kami, untuk memastikan ia berfungsi. Dan di sinilah Jenkins boleh membantu anda.
Tetapi dengan cerita: mari buat perubahan kecil, biarkan tugasan kecil, mari buat masalah dan segera cuba entah bagaimana membenamkannya ke dalam induk - tiada Jenkins akan membantu di sini. Kerana Jenkins hanya akan membantu anda menjalankan ujian.
Anda boleh melakukannya tanpa mereka. Ini tidak akan menyakiti anda sama sekali. Kerana matlamat amalan adalah untuk mengukur sekerap mungkin, supaya tidak membuang banyak masa untuk sebarang konflik pada masa hadapan.
Mari kita bayangkan bahawa atas sebab tertentu kita berada pada tahun 2020 tanpa Internet. Dan kami bekerja di dalam negara. Kami tidak mempunyai Jenkins. Ini baik. Anda masih boleh meneruskan dan membuat cawangan tempatan. Anda menulis beberapa kod di dalamnya. Kami menyelesaikan tugasan dalam 3-4 jam. Kami bertukar kepada master, melakukan git pull, dan menggabungkan cawangan kami di sana. sedia. Jika anda sering melakukan ini, tahniah, anda mempunyai Integrasi Berterusan!
Apakah bukti di dunia moden bahawa ia bernilai menghabiskan tenaga? Kerana secara umum ia sukar. Jika anda cuba bekerja seperti ini, anda akan faham bahawa beberapa perancangan kini akan terjejas, anda perlu menumpukan lebih banyak masa untuk tugas yang membusuk. Kerana jika anda melakukan manusia..., maka anda tidak akan dapat menerima dengan cepat dan, dengan itu, akan mendapat masalah. Anda tidak akan mempunyai latihan lagi.
Dan ia akan menjadi mahal. Ia tidak akan dapat berfungsi serta-merta mulai esok menggunakan Integrasi Berterusan. Anda semua akan mengambil masa yang sangat lama untuk membiasakannya, anda akan mengambil masa yang lama untuk membiasakan diri dengan tugasan yang membusuk, ia akan mengambil masa yang sangat lama untuk membiasakan diri untuk membuat semula amalan semakan, jika anda mempunyai satu . Kerana matlamat kami adalah untuk mencairkan hari ini. Dan jika anda melakukan semakan dalam masa tiga hari, maka anda menghadapi masalah dan Integrasi Berterusan tidak berfungsi untuk anda.
Tetapi adakah kita mempunyai bukti yang relevan sekarang yang memberitahu kita bahawa melabur dalam amalan ini masuk akal?
Perkara pertama yang terlintas di fikiran saya ialah State of DevOps. Ini adalah kajian yang telah dilakukan oleh lelaki itu selama 7 tahun. Kini mereka melakukannya sebagai organisasi bebas, tetapi di bawah Google.
Dan kajian 2018 mereka menunjukkan korelasi antara syarikat yang cuba menggunakan cawangan jangka pendek yang berintegrasi dengan cepat, kerap berintegrasi dan mempunyai penunjuk prestasi IT yang lebih baik.
Apakah penunjuk ini? Ini ialah 4 metrik yang mereka ambil daripada semua syarikat dalam soal selidik mereka: kekerapan penggunaan, masa utama untuk perubahan, masa untuk memulihkan perkhidmatan, menukar kadar kegagalan.
Dan, pertama, terdapat korelasi ini, kita tahu bahawa syarikat yang kerap mengukur mempunyai metrik yang lebih baik. Dan mereka mempunyai pembahagian syarikat kepada beberapa kategori: ini adalah syarikat perlahan yang menghasilkan sesuatu secara perlahan, berprestasi sederhana, berprestasi tinggi dan elit. Golongan elit ialah Netflix, Amazon, yang sangat pantas, melakukan segala-galanya dengan pantas, cantik dan cekap.
Kisah kedua, yang berlaku hanya sebulan yang lalu. Radar Teknologi mempunyai artikel hebat tentang Gitflow. Gitflow berbeza daripada semua yang lain kerana cawangannya berumur panjang. Terdapat cawangan keluaran yang hidup untuk masa yang lama, dan mempunyai cawangan yang juga hidup untuk masa yang lama. Amalan di Radar Teknologi ini telah berpindah ke HOLD. kenapa? Kerana orang ramai menghadapi kesakitan integrasi.
Jika cawangan anda hidup untuk masa yang sangat lama, ia tersekat, menjadi busuk, dan kami mula meluangkan lebih banyak masa untuk membuat beberapa jenis perubahan padanya.
Dan baru-baru ini pengarang Gitflow berkata bahawa jika matlamat anda ialah Integrasi Berterusan, jika matlamat anda ialah anda ingin melancarkan sekerap mungkin, maka Gitflow adalah idea yang tidak baik. Dia secara berasingan menambah pada artikel itu bahawa jika anda mempunyai bahagian belakang di mana anda boleh berusaha untuk ini, maka Gitflow tidak diperlukan untuk anda, kerana Gitflow akan melambatkan anda, Gitflow akan menimbulkan masalah untuk anda dengan penyepaduan.
Ini tidak bermakna Gitflow adalah buruk dan tidak boleh digunakan. Ia untuk majlis-majlis lain. Contohnya, apabila anda perlu menyokong beberapa versi perkhidmatan atau aplikasi, iaitu di mana anda memerlukan sokongan untuk jangka masa yang panjang.
Tetapi jika anda bercakap dengan orang yang menyokong perkhidmatan sedemikian, anda akan mendengar banyak kesakitan tentang fakta bahawa versi ini adalah 3.2, iaitu 4 bulan yang lalu, tetapi pembaikan ini tidak disertakan di dalamnya dan sekarang, untuk menjadikannya, anda perlu membuat banyak perubahan. Dan kini mereka tersekat lagi, dan kini mereka telah bermain-main selama seminggu cuba melaksanakan beberapa ciri baharu.
Seperti yang dinyatakan dengan betul oleh Alexander Kovalev dalam sembang, korelasi tidak sama dengan sebab musabab. Ini adalah benar. Iaitu, tidak ada sambungan langsung yang jika anda mempunyai Integrasi Berterusan, maka semua metrik akan menjadi hebat. Tetapi terdapat korelasi positif bahawa jika satu adalah satu, maka kemungkinan besar yang lain juga begitu. Bukan fakta, tetapi kemungkinan besar. Ia hanya korelasi.
Nampaknya kita sudah melakukan sesuatu, nampaknya kita sudah bergabung, tetapi bagaimana kita boleh memahami bahawa kita masih mempunyai Integrasi Berterusan, kita sering bergabung?
Jez Humble ialah pengarang Buku Panduan, Mempercepat, tapak web Penghantaran Berterusan dan buku Penghantaran Berterusan. Dia menawarkan ujian ini:
- Kod jurutera sampai kepada tuan setiap hari.
- Untuk setiap komitmen anda menjalankan ujian unit.
- Binaan dalam master jatuh, ia diperbaiki dalam masa kira-kira 10 minit.
Dia mencadangkan menggunakan ujian seperti ini untuk memastikan anda mempunyai latihan yang mencukupi.
Saya mendapati yang terakhir ini sedikit kontroversi. Iaitu, jika anda boleh membetulkannya dalam 10 minit, maka anda mempunyai Integrasi Berterusan, bunyinya agak pelik, pada pendapat saya, tetapi ia masuk akal. kenapa? Kerana jika anda sering membeku, ini bermakna perubahan anda adalah kecil. Jika perubahan kecil bermakna binaan induk anda rosak, maka anda boleh mencari contoh dengan cepat kerana perubahan itu kecil. Di sini anda mempunyai gabungan kecil, 20-30 baris di dalamnya berubah. Dan, dengan itu, anda boleh memahami dengan cepat apa sebabnya, kerana perubahannya kecil, anda mempunyai kawasan yang sangat kecil untuk mencari masalah itu.
Dan walaupun prod kami rosak selepas dikeluarkan, maka jika kita mempunyai amalan Integrasi Berterusan, adalah lebih mudah untuk kita bertindak, kerana perubahannya kecil. Ya, ini akan menjejaskan perancangan. Ini akan menyakitkan. Dan, mungkin, perkara yang paling sukar dalam amalan ini ialah membiasakan diri dengan memecahkan tugas, iaitu, bagaimana untuk melakukannya supaya anda boleh mengambil sesuatu dan melakukannya dalam beberapa jam dan pada masa yang sama lulus semakan, jika awak ada satu. Semakan adalah kesakitan yang berasingan.
Ujian unit hanyalah pembantu yang membantu anda memahami sama ada penyepaduan anda berjaya dan sama ada tiada yang rosak. Pada pendapat saya, ini juga tidak wajib sepenuhnya, kerana ini bukan titik amalan.
Ini adalah pengenalan ringkas kepada Integrasi Berterusan. Itu sahaja yang ada pada amalan ini. Saya bersedia untuk soalan.
Saya ringkaskan sekali lagi:
- Integrasi Berterusan bukan Jenkins, ia bukan Gitlab.
- Ini bukan alat, ia adalah amalan yang kami menggabungkan kod kami ke dalam induk sekerap mungkin.
- Kami melakukan ini untuk mengelakkan kesakitan yang sangat besar yang timbul dengan gabungan pada masa hadapan, iaitu, kami mengalami sedikit kesakitan sekarang supaya tidak mengalami lebih banyak pada masa hadapan. Itulah keseluruhannya.
- Di sisi terdapat komunikasi melalui kod, tetapi saya sangat jarang melihat ini, tetapi ini juga untuk tujuannya.
soalan
Apa yang perlu dilakukan dengan tugas yang tidak terurai?
mereput. Apa masalahnya? Bolehkah anda memberi contoh bahawa ada tugas dan ia tidak terurai?
Terdapat tugas yang tidak boleh diuraikan daripada perkataan "sepenuhnya", contohnya, tugas yang memerlukan kepakaran yang sangat mendalam dan yang sebenarnya boleh diselesaikan dalam tempoh sebulan untuk mencapai hasil yang boleh dihadam.
Sekiranya saya memahami anda dengan betul, maka terdapat beberapa tugas yang besar dan kompleks, yang hasilnya akan dapat dilihat hanya dalam sebulan?
Ya betul. Ya, adalah mungkin untuk menilai hasilnya tidak lebih awal daripada sebulan.
baiklah. Secara umum ini tidak menjadi masalah. kenapa? Kerana dalam kes ini, apabila kita bercakap tentang ranting, kita tidak bercakap tentang ranting yang mempunyai ciri. Ciri boleh menjadi besar dan kompleks. Mereka boleh menjejaskan sejumlah besar komponen. Dan mungkin kita tidak boleh melakukannya sepenuhnya dalam satu cabang. Ini baik. Kita hanya perlu memecahkan cerita ini. Jika sesuatu ciri tidak bersedia sepenuhnya, ini tidak bermakna bahawa beberapa bahagian kodnya tidak boleh digabungkan. Anda menambah, katakan, penghijrahan dan terdapat beberapa peringkat dalam ciri tersebut. Katakan anda mempunyai peringkat - buat migrasi, tambah kaedah baharu. Dan anda sudah boleh mengukur perkara ini setiap hari.
baik. Apa gunanya?
Apa gunanya membunuh perkara kecil setiap hari?
Ya.
Jika mereka memecahkan sesuatu, anda akan melihatnya dengan serta-merta. Anda mempunyai kepingan kecil yang telah memecahkan sesuatu, lebih mudah untuk anda membaikinya. Intinya ialah menggabungkan sekeping kecil sekarang adalah lebih mudah daripada menggabungkan sesuatu yang besar dalam beberapa minggu. Dan perkara ketiga ialah jurutera lain akan bekerja dengan versi kod semasa. Mereka akan melihat bahawa beberapa migrasi telah ditambahkan di sini, dan kemudian beberapa kaedah telah muncul yang mereka juga mungkin mahu gunakan. Semua orang akan melihat apa yang berlaku dalam kod anda. Untuk tiga perkara inilah amalan dilakukan.
Terima kasih, isu ini telah ditutup!
(Oleg Soroka) Bolehkah saya menambah? Anda mengatakan semuanya dengan betul, saya hanya ingin menambah satu frasa.
Jadi.
Dengan Penyepaduan Berterusan, kod itu digabungkan menjadi cawangan biasa bukan apabila ciri itu sudah sedia sepenuhnya, tetapi apabila binaan berhenti pecah. Dan anda boleh komited dengan selamat untuk menguasai seberapa banyak kali sehari yang anda mahu. Aspek kedua ialah jika atas sebab tertentu anda tidak boleh memecahkan tugas bulanan kepada tugas selama sekurang-kurangnya tiga hari, saya diam kira-kira tiga jam, maka anda mempunyai masalah besar. Dan hakikat bahawa anda tidak mempunyai Integrasi Berterusan adalah yang paling kecil daripada masalah ini. Ini bermakna anda menghadapi masalah dengan seni bina dan amalan kejuruteraan sifar. Kerana walaupun ini adalah penyelidikan, maka dalam apa jua keadaan ia mesti dirumuskan dalam bentuk hipotesis atau kitaran.
Kami bercakap tentang 4 metrik yang membezakan syarikat yang berjaya daripada yang ketinggalan. Kita masih perlu hidup untuk melihat 4 metrik ini. Jika purata tugasan anda mengambil masa sebulan untuk diselesaikan, maka saya akan menumpukan pada metrik ini terlebih dahulu. Saya akan menurunkannya kepada 3 hari dahulu. Dan selepas itu saya mula berfikir tentang Berterusan.
Adakah saya memahami anda dengan betul bahawa anda berpendapat bahawa secara umum tidak ada gunanya melabur dalam amalan kejuruteraan jika sebarang tugas mengambil masa sebulan untuk diselesaikan?
Anda mempunyai Integrasi Berterusan. Dan terdapat topik sedemikian yang dalam 10 minit anda boleh sama ada membetulkan atau melancarkannya kembali. Bayangkan anda melancarkannya. Selain itu, anda juga mempunyai penggunaan yang berterusan, anda melancarkannya untuk prod dan baru menyedari bahawa sesuatu telah berlaku. Dan anda perlu melancarkannya semula, tetapi anda telah memindahkan pangkalan data anda. Anda sudah mempunyai skema pangkalan data versi seterusnya, lebih-lebih lagi, anda juga mempunyai beberapa jenis sandaran, dan data juga ditulis di sana.
Dan apakah alternatif yang anda ada? Jika anda melancarkan semula kod itu, maka ia tidak lagi boleh berfungsi dengan pangkalan data yang dikemas kini ini.
Pangkalan hanya bergerak ke hadapan, ya.
Orang yang mempunyai amalan kejuruteraan yang lemah berkemungkinan besar belum membaca buku tebal tentang... sama ada. Apa yang perlu dilakukan dengan sandaran? Jika anda memulihkan daripada sandaran, ini bermakna anda kehilangan data yang telah anda kumpulkan pada masa itu. Sebagai contoh, kami bekerja selama tiga jam dengan versi baharu pangkalan data, pengguna mendaftar di sana. Anda menolak sandaran lama kerana skema tidak berfungsi dengan versi baharu, jadi anda telah kehilangan pengguna ini. Dan mereka tidak berpuas hati, mereka bersumpah.
Untuk menguasai rangkaian penuh amalan yang menyokong Integrasi Berterusan dan Penyampaian Berterusan, tidak cukup dengan hanya belajar menulis.... Pertama, mungkin terdapat banyak daripada mereka, ia akan menjadi tidak praktikal. Tambahan pula terdapat banyak amalan lain seperti Saintifik. Terdapat amalan sedemikian, GitHub mempopularkannya pada satu masa. Ini adalah apabila anda mempunyai kedua-dua kod lama dan kod baharu berjalan pada masa yang sama. Ini adalah apabila anda membuat ciri yang belum selesai, tetapi ia boleh mengembalikan beberapa nilai: sama ada sebagai fungsi atau sebagai API Rehat. Anda melaksanakan kedua-dua kod baharu dan kod lama, dan bandingkan perbezaan di antara mereka. Dan jika terdapat perbezaan, maka anda log acara ini. Dengan cara ini anda tahu bahawa anda mempunyai ciri baharu yang sedia untuk dilancarkan di atas ciri lama jika anda tidak mempunyai percanggahan antara kedua-duanya untuk masa tertentu.
Terdapat beratus-ratus amalan sedemikian. Saya cadangkan bermula dengan pembangunan transbase. Dia tidak 100% pada Integrasi Berterusan, tetapi amalannya adalah sama, seseorang tidak boleh hidup dengan baik tanpa yang lain.
Adakah anda memberikan pembangunan transbase sebagai contoh di mana anda boleh melihat amalan atau adakah anda mencadangkan orang ramai mula menggunakan debelopment transbase?
Lihatlah, kerana mereka tidak akan dapat menggunakannya. Untuk menggunakannya, anda perlu banyak membaca. Dan apabila seseorang bertanya: "Apa yang perlu dilakukan dengan ciri yang mengambil masa sebulan, ini bermakna dia belum membaca tentang pembangunan transbase." Saya tidak akan mengesyorkannya lagi. Saya akan menasihatkan untuk memberi tumpuan semata-mata pada topik bagaimana untuk membahagikan tugas besar kepada tugas yang lebih kecil dari segi seni bina dengan betul. Ini adalah intipati penguraian.
Penguraian adalah salah satu alat arkitek. Kami mula-mula melakukan analisis, kemudian penguraian, kemudian sintesis, kemudian integrasi. Dan ini adalah bagaimana semuanya berfungsi untuk kita. Dan kita masih perlu berkembang kepada Integrasi Berterusan melalui penguraian. Soalan timbul pada peringkat pertama, dan kita sudah bercakap tentang peringkat keempat, iaitu lebih kerap kita melakukan penyepaduan, lebih baik. Masih terlalu awal untuk melakukan ini; adalah baik untuk mengurangkan monolit anda terlebih dahulu.
Anda perlu melukis beberapa anak panah dan segi empat sama pada beberapa rajah. Anda tidak boleh mengatakan bahawa sekarang saya akan menunjukkan gambar rajah seni bina aplikasi baharu dan menunjukkan satu petak, di dalamnya terdapat butang hijau untuk aplikasi itu. Walau apa pun, akan ada lebih banyak petak dan anak panah. Setiap rajah yang saya lihat mempunyai lebih daripada satu. Dan penguraian, walaupun pada tahap perwakilan grafik, sudah berlaku. Oleh itu, petak boleh dibuat bebas. Jika tidak, maka saya mempunyai soalan besar untuk arkitek.
Terdapat soalan dari sembang: "Jika semakan adalah wajib dan mengambil masa yang lama, mungkin sehari atau lebih?"
Anda mempunyai masalah dengan latihan. Semakan tidak boleh bertahan sehari atau lebih. Ini adalah cerita yang sama dengan soalan sebelumnya, hanya sedikit lebih lembut. Jika semakan berjalan selama sehari, kemungkinan besar semakan ini akan melakukan beberapa perubahan yang sangat besar. Ini bermakna ia perlu dibuat lebih kecil. Dalam pembangunan transbase, yang Oleg disyorkan, terdapat cerita yang dipanggil kajian berterusan. Ideanya ialah kami membuat permintaan tarik yang kecil dengan sengaja, kerana kami berusaha untuk bergabung secara berterusan dan sedikit demi sedikit. Maka permintaan tarik menukar satu abstraksi atau 10 baris. Terima kasih kepada semakan ini, kami mengambil masa beberapa minit.
Jika semakan mengambil masa sehari atau lebih, ada yang tidak kena. Pertama, anda mungkin mempunyai beberapa masalah dengan seni bina. Atau ini adalah sekeping kod yang besar, 1 baris, sebagai contoh. Atau seni bina anda sangat kompleks sehingga seseorang tidak dapat memahaminya. Ini adalah masalah yang sedikit menyebelahi, tetapi ia juga perlu diselesaikan. Mungkin tiada keperluan untuk semakan sama sekali. Kita perlu memikirkan perkara ini juga. Semakan adalah perkara yang melambatkan anda. Ia mempunyai kelebihannya secara umum, tetapi anda perlu memahami mengapa anda melakukannya. Adakah ini cara untuk anda menyampaikan maklumat dengan cepat, adakah ini cara untuk anda menetapkan beberapa standard secara dalaman atau apa? Mengapa anda memerlukan ini? Kerana semakan perlu dilakukan sama ada sangat cepat atau dibatalkan sama sekali. Ia seperti pembangunan transbase - ceritanya sangat cantik, tetapi hanya untuk lelaki matang.
Berkenaan dengan 4 metrik, saya masih akan mengesyorkan mengalih keluarnya untuk memahami perkara ini membawa kepada. Tengok nombor, tengok gambar, betapa teruknya semuanya.
(Dmitry) Saya bersedia untuk mengadakan perbincangan tentang perkara ini dengan anda. Nombor dan metrik semuanya hebat, amalannya hebat. Tetapi anda perlu memahami sama ada perniagaan memerlukannya. Terdapat perniagaan yang tidak memerlukan perubahan yang pantas seperti itu. Saya tahu syarikat di mana perubahan tidak boleh dibuat setiap 15 minit. Dan bukan kerana mereka sangat teruk. Ini adalah kitaran hidup. Dan untuk menjadikan ciri cawangan, ciri togol, anda memerlukan pengetahuan yang mendalam.
Ia rumit. Jika anda ingin membaca cerita tentang ciri togol dengan lebih terperinci, saya sangat mengesyorkannya . Dan terdapat artikel menarik oleh Martin Fowler tentang ciri togol: jenis apa yang ada, kitaran hayat, dll. Ciri togol adalah rumit.
Dan anda masih belum menjawab soalan: "Adakah Jenkins diperlukan atau tidak?"
Jenkins tidak diperlukan dalam apa jua keadaan sebenarnya. Secara serius, alat: Jenkins, Gitlab akan membawa anda kemudahan. Anda akan melihat bahawa pemasangan dipasang atau tidak dipasang. Mereka boleh membantu anda, tetapi mereka tidak akan memberi anda latihan. Mereka hanya boleh memberi anda bulatan - Ok, bukan Ok. Dan kemudian, jika anda juga menulis ujian, kerana jika tidak ada ujian, maka ia hampir tidak berguna. Oleh itu, ia diperlukan kerana ia lebih mudah, tetapi secara umum anda boleh hidup tanpanya, anda tidak akan kehilangan banyak.
Iaitu, jika anda mempunyai amalan, adakah itu bermakna anda tidak memerlukannya?
betul tu. Saya mengesyorkan ujian Jez Humble. Di sana saya mempunyai sikap ambivalen terhadap titik terakhir. Tetapi secara umum, jika anda mempunyai tiga perkara, anda bergabung secara berterusan, anda menjalankan ujian pada komit dalam induk, anda dengan cepat membetulkan binaan dalam induk, maka mungkin anda tidak memerlukan apa-apa lagi.
Sementara kami menunggu soalan daripada peserta, saya ada satu soalan. Kami hanya bercakap tentang kod produk. Pernahkah anda menggunakannya untuk kod infrastruktur? Adakah kod yang sama, adakah ia mempunyai prinsip yang sama dan kitaran hayat yang sama, atau adakah terdapat kitaran hayat dan prinsip yang berbeza? Biasanya, apabila semua orang bercakap tentang Integrasi dan Pembangunan Berterusan, semua orang lupa bahawa terdapat juga kod infrastruktur. Dan kebelakangan ini semakin banyak. Dan patutkah semua peraturan ini dibawa ke sana?
Walaupun tidak sepatutnya, ia akan menjadi hebat kerana ia akan menjadikan hidup lebih mudah dengan cara yang sama. Sebaik sahaja kami bekerja dengan kod, bukan dengan skrip bash, tetapi kami mempunyai kod biasa.
Berhenti, berhenti, skrip bash juga adalah kod. Jangan sentuh cinta lama saya.
Baiklah, saya tidak akan menginjak kenangan anda. Saya tidak suka secara peribadi untuk bash. Ia rosak hodoh dan menakutkan sepanjang masa. Dan ia sering pecah tanpa diduga, itulah sebabnya saya tidak menyukainya. Tetapi okey, katakan anda mempunyai kod bash. Mungkin saya benar-benar tidak faham dan terdapat rangka kerja ujian biasa di luar sana. Saya hanya tidak tahu. Dan kita mendapat faedah yang sama.
Sebaik sahaja kami bekerja dengan infrastruktur sebagai kod, kami mendapat semua masalah yang sama seperti pembangun. Beberapa bulan yang lalu, saya menghadapi situasi di mana rakan sekerja menghantar permintaan tarik kepada saya untuk 1 baris dalam bash. Dan anda melepak di ulasan selama 000 jam. Masalah yang sama timbul. Ia masih kod. Dan ia masih merupakan kerjasama. Kami terperangkap dengan permintaan tarik dan kami terjebak dengan fakta bahawa kami menyelesaikan konflik gabungan yang sama dalam bash yang sama, sebagai contoh.
Saya kini sangat aktif melihat keseluruhan perkara ini pada pengaturcaraan infra yang paling indah. Saya kini telah membawa Pulumi ke dalam infrastruktur. Ini adalah pengaturcaraan dalam bentuk yang paling tulen. Di sana ia lebih bagus, kerana saya mempunyai semua keupayaan bahasa pengaturcaraan, iaitu saya membuat togol cantik secara tiba-tiba dengan ifs yang sama dan semuanya baik-baik saja. Maksudnya, perubahan saya sudah ada pada tuan. Semua orang sudah boleh melihatnya. Jurutera lain tahu mengenainya. Ia telah mempengaruhi sesuatu di sana. Walau bagaimanapun, ia tidak didayakan untuk semua infrastruktur. Ia dihidupkan untuk bangku ujian saya, sebagai contoh. Oleh itu, untuk menjawab soalan anda sekali lagi, adalah perlu. Ia menjadikan kehidupan lebih mudah untuk kami, sebagai jurutera yang bekerja dengan kod, dengan cara yang sama.
Jika orang lain mempunyai soalan?
Saya ada satu soalan. Saya mahu meneruskan perbincangan dengan Oleg. Secara umum, saya fikir anda betul, bahawa jika tugas mengambil masa sebulan untuk diselesaikan, maka anda mempunyai masalah dengan seni bina, anda mempunyai masalah dengan analisis, penguraian, perancangan, dll. Tetapi saya mempunyai perasaan bahawa jika anda mula mencuba hidup mengikut Integrasi Berterusan, maka anda akan mula membetulkan kesakitan dengan perancangan, kerana anda tidak akan terlepas daripadanya di tempat lain.
(Oleg) Ya, betul. Amalan ini adalah setanding dalam usaha dengan mana-mana amalan serius mengubah budaya yang lain. Perkara yang paling sukar untuk diatasi adalah tabiat, terutamanya tabiat buruk. Dan jika untuk melaksanakan amalan ini, perubahan serius dalam tabiat orang di sekeliling anda diperlukan: pemaju, pengurusan, pengurus pengeluaran, maka kejutan menanti anda.
Apakah kejutan yang boleh berlaku? Katakan anda memutuskan bahawa anda akan menyepadukan lebih kerap. Dan anda mempunyai beberapa perkara lain yang terikat dengan penyepaduan, contohnya, artifak. Dan dalam syarikat anda, sebagai contoh, terdapat dasar bahawa setiap artifak mesti diambil kira dalam beberapa cara dalam beberapa jenis sistem penyimpanan artifak. Dan ia mengambil sedikit masa. Seseorang perlu menandai kotak bahawa dia, sebagai pengurus keluaran, telah menguji artifak ini untuk memastikan ia sedia untuk dikeluarkan dalam pengeluaran. Jika ia mengambil masa 5-10-15 minit, tetapi anda melakukan susun atur sekali seminggu, maka menghabiskan setengah jam sekali seminggu adalah cukai yang kecil.
Jika anda melakukan Integrasi Berterusan 10 kali sehari, maka 10 kali perlu didarabkan dengan 30 minit. Dan ini melebihi jumlah masa bekerja pengurus keluaran ini. Dia hanya penat melakukannya. Terdapat kos tetap untuk beberapa amalan. Itu sahaja.
Dan anda perlu sama ada membatalkan peraturan ini supaya anda tidak lagi melakukan sampah seperti itu, iaitu anda tidak memberikan ijazah secara manual untuk sepadan dengan sesuatu. Anda bergantung sepenuhnya pada beberapa set ujian kesediaan automatik.
Dan jika anda memerlukan bukti daripada seseorang, supaya bos menandatanganinya, dan anda tidak masuk ke dalam pengeluaran tanpa Vasya mengatakan bahawa dia membenarkannya, dll. - semua omong kosong ini menghalang pengamalnya. Kerana jika terdapat beberapa aktiviti yang dikaitkan dengan cukai, maka semuanya meningkat 100 kali ganda. Oleh itu, pergeseran selalunya tidak akan disambut dengan kegembiraan oleh semua orang. Sebab tabiat orang susah nak ubah.
Apabila seseorang melakukan kerja biasa, dia melakukannya hampir tanpa berfikir. Beban kognitifnya adalah sifar. Dia hanya bermain-main dengannya, dia sudah mempunyai senarai semak dalam kepalanya, dia melakukannya seribu kali. Dan sebaik sahaja anda datang dan beritahu dia: "Mari batalkan amalan ini dan perkenalkan amalan baharu mulai Isnin," baginya ia menjadi beban kognitif yang kuat. Dan ia datang kepada semua orang sekaligus.
Oleh itu, perkara paling mudah, walaupun tidak semua orang mampu memiliki kemewahan ini, tetapi inilah yang saya selalu lakukan, ini adalah berikut. Jika projek baharu dimulakan, maka biasanya semua amalan yang belum diuji serta-merta akan dijejalkan ke dalam projek ini. Walaupun projek itu masih muda, kami tidak benar-benar mengambil risiko apa-apa. Belum ada Prod, belum ada apa-apa untuk dimusnahkan. Oleh itu, ia boleh digunakan sebagai latihan. Pendekatan ini berfungsi. Tetapi tidak semua syarikat mempunyai peluang untuk memulakan projek sedemikian selalunya. Walaupun ini juga agak pelik, kerana kini terdapat transformasi digital yang lengkap, semua orang mesti melancarkan eksperimen untuk bersaing dengan pesaing.
Di sini anda sampai pada kesimpulan bahawa anda mesti terlebih dahulu mempunyai pemahaman tentang apa yang perlu anda lakukan. Dunia tidak ideal, dan prod juga tidak ideal.
Ya, perkara ini saling berkaitan.
Perniagaan juga tidak sentiasa memahami bahawa mereka perlu pergi ke cara ini.
Terdapat keadaan di mana tiada perubahan boleh dilakukan sama sekali. Ini adalah situasi di mana terdapat lebih banyak tekanan kepada pasukan. Pasukan itu sudah agak hangus. Dia tidak mempunyai masa lapang untuk sebarang eksperimen. Mereka bekerja pada ciri dari pagi hingga petang. Dan pengurusan mempunyai ciri yang semakin sedikit. Semakin banyak yang diperlukan. Dalam keadaan sedemikian, tiada perubahan boleh dilakukan sama sekali. Pasukan hanya boleh diberitahu bahawa esok kami akan melakukan perkara yang sama seperti semalam, kami hanya perlu membuat lebih sedikit ciri. Dalam pengertian ini, tiada peralihan kepada mana-mana amalan boleh dilakukan. Ini adalah keadaan klasik apabila tidak ada masa untuk mengasah kapak, pokok perlu ditebang, jadi mereka memotongnya dengan kapak yang kusam. Tiada petua mudah di sini.
(Dmitry) Saya akan membacakan penjelasan daripada sembang: "Tetapi kami memerlukan banyak liputan ujian pada tahap yang berbeza. Berapa banyak masa yang diperuntukkan untuk ujian? Ia agak mahal dan mengambil banyak masa.β
(Oleg) Ini adalah salah tanggapan klasik. Perlu ada ujian yang mencukupi untuk anda yakin. Integrasi Berterusan bukanlah satu perkara di mana 100% daripada ujian dilakukan terlebih dahulu dan selepas itu anda mula menggunakan amalan ini. Integrasi Berterusan mengurangkan beban kognitif anda kerana hakikat bahawa setiap perubahan yang anda lihat dengan mata anda sangat jelas sehingga anda memahami sama ada ia akan memecahkan sesuatu atau tidak, walaupun tanpa ujian. Anda boleh menguji ini dengan cepat dalam kepala anda kerana perubahannya kecil. Walaupun anda hanya mempunyai penguji manual, ia juga lebih mudah untuk mereka. Anda melancarkan dan berkata: "Lihat, adakah sesuatu yang rosak?" Mereka memeriksa dan berkata, "Tidak, tiada yang rosak." Kerana penguji tahu di mana hendak mencari. Anda mempunyai satu komitmen yang dikaitkan dengan satu keping kod. Dan ini dieksploitasi oleh tingkah laku tertentu.
Di sini anda, sudah tentu, dihiasi.
(Dmitry) Saya tidak bersetuju di sini. Terdapat amalan - pembangunan yang didorong oleh ujian, yang akan menyelamatkan anda daripada ini.
(Oleg) Nah, saya belum sampai ke tahap itu. Ilusi pertama ialah anda perlu menulis 100% ujian atau anda tidak perlu melakukan Integrasi Berterusan sama sekali. Ianya tidak betul. Ini adalah dua amalan yang selari. Dan mereka tidak bergantung secara langsung. Liputan ujian anda hendaklah optimum. Optimum - ini bermakna anda sendiri yakin bahawa kualiti tuan di mana tuan anda kekal selepas komit membolehkan anda menekan butang "Kerahkan" dengan yakin pada petang Jumaat yang mabuk. Bagaimana anda mencapai ini? Melalui semakan, melalui liputan, melalui pemantauan yang baik.
Pemantauan yang baik tidak dapat dibezakan daripada ujian. Jika anda menjalankan ujian sekali pada pra prod, maka mereka menyemak semua skrip pengguna anda sekali dan itu sahaja. Dan jika anda menjalankannya dalam gelung yang tidak berkesudahan, maka ini adalah sistem pemantauan anda yang digunakan, yang menguji segala-galanya tanpa henti - sama ada ia ranap atau tidak. Dalam kes ini, satu-satunya perbezaan adalah sama ada ia dilakukan sekali atau dua kali. Satu set ujian yang sangat baik... berjalan tanpa henti, ini adalah pemantauan. Dan pemantauan yang betul sepatutnya seperti ini.
Dan oleh itu, bagaimana sebenarnya anda akan mencapai keadaan ini apabila anda bersiap pada petang Jumaat dan pulang ke rumah adalah soalan lain. Mungkin anda hanya seorang bajingan yang berani.
Mari kita kembali sedikit kepada Integrasi Berterusan. Kami lari ke dalam amalan kompleks yang sedikit berbeza.
Dan ilusi kedua ialah MVP, kata mereka, perlu dilakukan dengan cepat, jadi ujian tidak diperlukan di sana sama sekali. Tidak pasti dengan cara itu. Hakikatnya ialah apabila anda menulis cerita pengguna dalam MVP, anda boleh sama ada mengembangkannya pada bola, iaitu, anda mendengar bahawa terdapat beberapa jenis cerita pengguna dan segera berlari untuk mengekodnya, atau anda boleh bekerja menggunakan TDD. Dan menurut TDD, seperti yang ditunjukkan oleh amalan, ia tidak mengambil masa yang lebih lama, iaitu ujian adalah kesan sampingan. Amalan TDD bukan tentang ujian. Walaupun apa yang dipanggil Test Driven Development, ia bukan mengenai ujian sama sekali. Ini juga agak pendekatan seni bina. Ini adalah pendekatan untuk menulis dengan tepat apa yang diperlukan dan bukan menulis apa yang tidak diperlukan. Ini adalah amalan memfokuskan pada lelaran seterusnya pemikiran anda dari segi mencipta seni bina aplikasi.
Oleh itu, tidak begitu mudah untuk menghilangkan ilusi ini. MVP dan ujian tidak bercanggah antara satu sama lain. Malah, sebaliknya, jika anda melakukan MVP menggunakan latihan TDD, maka anda akan melakukannya dengan lebih baik dan lebih cepat daripada jika anda melakukannya tanpa latihan sama sekali, tetapi menggunakan bola.
Ini adalah idea yang sangat tidak jelas dan kompleks. Apabila anda mendengar bahawa sekarang saya akan menulis lebih banyak ujian dan pada masa yang sama saya akan melakukan sesuatu dengan lebih cepat, ia kedengaran sama sekali tidak mencukupi.
(Dmitry) Ramai orang di sini, apabila mereka memanggil MVP, orang terlalu malas untuk menulis sesuatu yang biasa. Dan ini masih perkara yang berbeza. Tidak perlu mengubah MVP menjadi perkara buruk yang tidak berfungsi.
Ya, ya, anda betul.
Dan kemudian tiba-tiba MVP dalam prod.
Selamanya dan selamanya.
Dan TDD berbunyi sangat luar biasa apabila anda mendengar bahawa anda menulis ujian dan nampaknya melakukan lebih banyak kerja. Bunyinya sangat pelik, tetapi sebenarnya ia ternyata lebih cepat dan lebih cantik dengan cara ini. Apabila anda menulis ujian, anda sudah banyak berfikir di kepala anda tentang kod yang akan dipanggil dan bagaimana, serta tingkah laku yang kami harapkan daripadanya. Anda tidak hanya mengatakan saya menulis beberapa fungsi dan ia melakukan sesuatu. Pada mulanya anda menyangka bahawa dia mempunyai keadaan begini dan begitu, dia akan dipanggil begitu dan begitu. Anda menutup perkara ini dengan ujian dan daripada ini anda memahami bagaimana antara muka anda akan kelihatan di dalam kod anda. Ini mempunyai kesan yang besar terhadap seni bina. Kod anda secara automatik menjadi lebih modular, kerana anda mula-mula cuba memahami cara anda akan mengujinya, dan kemudian menulisnya.
Apa yang berlaku kepada saya dengan TDD ialah pada satu ketika saya mengupah mentor Ruby semasa saya masih menjadi pengaturcara Ruby. Dan dia berkata: "Mari kita lakukan mengikut TDD." Saya fikir: "Sial, sekarang saya perlu menulis sesuatu tambahan." Dan kami bersetuju bahawa dalam masa dua minggu saya akan menulis semua kod kerja dalam Python menggunakan TDD. Selepas dua minggu, saya menyedari bahawa saya tidak mahu kembali. Selepas dua minggu cuba menerapkan ini di mana-mana, anda menyedari betapa mudahnya untuk anda hanya berfikir. Tetapi ini tidak jelas, jadi saya mengesyorkan kepada semua orang bahawa jika anda mempunyai perasaan bahawa TDD adalah sukar, memakan masa dan tidak perlu, cuba kekal dengannya selama dua minggu sahaja. Dua sudah cukup untuk saya.
(Dmitry) Kita boleh mengembangkan idea ini dari sudut pandangan operasi infrastruktur. Sebelum kami melancarkan sesuatu yang baharu, kami melakukan pemantauan dan kemudian melancarkan. Dalam kes ini, pemantauan menjadi ujian biasa bagi kami. Dan ada pembangunan melalui pemantauan. Tetapi hampir semua orang mengatakan bahawa ia panjang, saya malas, saya membuat draf sementara. Jika kami telah melakukan pemantauan biasa, kami memahami keadaan sistem CI. Dan sistem CI mempunyai banyak pemantauan. Kami memahami keadaan sistem, kami memahami apa yang ada di dalamnya. Dan semasa pembangunan, kami hanya membuat sistem supaya ia mencapai keadaan yang dikehendaki.
Amalan-amalan ini telah diketahui sejak sekian lama. Kami membincangkan perkara ini kira-kira 4 tahun yang lalu. Tetapi dalam 4 tahun boleh dikatakan tiada apa yang berubah.
Tetapi atas nota ini, saya mencadangkan untuk menamatkan perbincangan rasmi.
Video (dimasukkan sebagai elemen media, tetapi atas sebab tertentu tidak berfungsi):
Sumber: www.habr.com