Garis Panduan Utama untuk Integrasi Berterusan dan Jenkins CI Server

mata utama

Integrasi Berterusan (CI) dan Jenkins CI Server adalah alat yang sangat diperlukan dalam pembangunan perisian moden, yang membantu pasukan melepaskan perisian berkualiti tinggi dan menjimatkan masa dengan mengautomasikan proses berulang.
CI menekankan automasi ujian, membolehkan jurutera ujian memberi tumpuan kepada ujian penerokaan dan kes kelebihan sambil memastikan kualiti setiap komit pada cawangan tertentu dalam beberapa minit penyerahan pemaju.
Jenkins CI Server adalah alat CI sumber terbuka yang boleh disesuaikan dengan pemalam sedia ada atau dengan membuat pemalam baru. Ia menyokong bangunan selari dengan memberikan tugas pada pelbagai mesin dan mengendalikan integrasi projek berterusan dalam pelbagai bahasa, termasuk Python.
Walaupun Jenkins memerlukan lebih banyak persediaan dan penyelenggaraan, fleksibiliti dan kawalannya, serta ciri sumber terbuka percuma menjadikannya pilihan yang kuat ke atas pelayan CI yang lain. Ia juga mengintegrasikan dengan pelbagai sistem kawalan versi, menjadikannya alat sejagat untuk projek yang berbeza.

Artikel ini pada asalnya diterbitkan di TestProject - Blog Automasi Ujian

Berikut ini akan memperkenalkan secara terperinci Integrasi Berterusan (CI), amalan penting dalam pembangunan perisian, dan Jenkins, alat integrasi berterusan sumber industri standard. Dengan melaksanakan integrasi berterusan dan pelayan Jenkins CI, anda akan mengetahui bagaimana penyebaran Jenkins dapat membantu pasukan pembangunan anda melepaskan perisian berkualiti tinggi dan menjimatkan masa yang berharga.

Ingin mengetahui lebih lanjut mengenai Jenkins dan integrasi berterusan? Sila periksa pautan berikut:

---

Rakaman Skrin: Alat integrasi yang berterusan menyokong BitBucket?

menyediakan dan membina projek PHP di Jenkins
integrasi berterusan dengan Jenkins
Pengenalan semula Jenkins: Ujian Automatik Menggunakan Pipelin
Pemasangan dan Perlindungan Jenkins
Amalan pembangunan perisian moden memerlukan penggunaan perisian berfungsi sepenuhnya secepat mungkin atau kerap dalam persekitaran pengeluaran. Sebagai contoh, pendekatan tangkas menguatkuasakan tingkah laku ini secara langsung dengan mempunyai pasukan bekerja dengan kenaikan kecil dan menyebarkannya ke persekitaran pengeluaran selepas setiap pecut (baca: strategi automasi ujian untuk projek tangkas).

---

Pasukan pembangunan menghabiskan berbulan -bulan membangunkan perisian dan kemudian lulus ke QA, UAT dan semua barisan pengeluaran tidak lagi wujud. Hari ini, tumpuannya adalah untuk mempunyai perisian yang berfungsi sepenuhnya dan tidak pernah membenarkan situasi yang membahayakan kualiti perisian, seperti memperkenalkan perubahan perisian penting pada akhir kitaran pelepasan. Di sinilah integrasi berterusan dimainkan.

Apa itu CI?

CI adalah amalan yang menguatkuasakan strategi untuk sering mengintegrasikan kod yang diuji ke dalam cabang projek yang stabil. Saya ingin menekankan "kod yang diuji" khususnya, kerana ini bermakna fungsi yang dibangunkan pada cawangan berasingan juga diuji dan oleh itu diintegrasikan ke dalam cawangan yang stabil.

siapa yang melakukan CI?

Biasanya, jurutera DevOps biasanya bertanggungjawab untuk menubuhkan saluran paip CI. Hari ini, peranan jurutera DevOps sangat mirip dengan jurutera ujian, kerana kedua -duanya memastikan kualiti proses dan perisian. Saya biasanya mengatakan bahawa QA dan pengeluaran adalah persimpangan terdekat kepada pelanggan. Dalam pengertian ini, CI menyediakan jurutera ujian dengan alat yang sangat kuat untuk meningkatkan proses keseluruhan dan kualiti perisian dengan aktif mengambil bahagian dalam bidang berikut:

• Automasi ujian: Beberapa tahun yang lalu, orang membincangkan ujian manual dan ujian automatik. Dengan CI, pengujian automasi menjadi sangat diperlukan, yang akhirnya akan menjimatkan banyak masa berharga yang memberi tumpuan kepada tugas ujian lain. Ia juga bernilai menyebut bahawa ujian manual dan ujian automatik tidak boleh saling eksklusif.
• Laporan Ujian: Untuk laporan ujian di CI, kita boleh menggunakan penyelesaian pelaporan sedia ada atau membina modul pelaporan kita sendiri. Dalam kedua -dua kes ini, ini jelas menunjukkan bagaimana kod aplikasi kami berada dalam setiap binaan. Adalah penting bahawa semua ahli pasukan pembangunan mempunyai akses kepada maklumat ini dan akan terus berfungsi untuk meningkatkan kualiti kod.
• Proses Penyebaran: Jurutera ujian lebih terlibat dalam proses penempatan aplikasi, yang menyediakan maklumat tambahan mengenai seni bina dalaman alat atau rangka kerja automasi ujian yang digunakan. Pengetahuan ini sangat penting, terutamanya apabila mengenal pasti masalah aplikasi "tersembunyi".

Manfaat CI

• CI menekankan automasi ujian, membolehkan jurutera ujian memberi tumpuan kepada ujian penerokaan, ujian kes kelebihan, dan juga mencari kaedah ujian baru.
• Kualiti komit tertentu pada cawangan tertentu akan muncul dalam beberapa minit dari penyerahan pemaju.
• Selepas kod telah diuji di cawangan, sangat berhati -hati untuk mengintegrasikan ke dalam cawangan yang stabil (proses CI harus menjalankan operasi ini). Penggunaan aplikasi akan dilaksanakan secara automatik sekali dengan betul, tanpa arahan berulang.
• Semua faedah ini meningkat secara eksponen dari perspektif pasukan.

Senario CI tipikal

Pasukan pembangunan mempunyai repositori kawalan versi kod sumber sendiri yang mengandungi projek (biasanya GitHub hari ini). Cawangan yang stabil (cawangan utama) sering dianggap sebagai cawangan kerja dan jarang mengembangkan ciri -ciri baru secara langsung di cawangan utama. Sebaliknya, pemaju membuat cawangan mereka sendiri untuk membangunkan ciri -ciri baru (Cawangan A ciri a). Apabila perubahan ditolak ke repositori pada cawangan tertentu dan pemaju membuat permintaan tarik, beberapa set ujian asas (ujian asap) harus dilakukan terhadap cawangan itu. Dari perspektif CI, ini biasanya bermaksud berikut:

Apabila proses CI selesai, terdapat beberapa keperluan dari perspektif jurutera ujian dan pemaju:

• penguji: menguji semula fungsi pada cawangan a Lagi
• pemaju: pemaju lain menjalankan ulasan kod rakan sebaya untuk memastikan bahawa kod tersebut mempunyai kualiti yang cukup baik
• Pembangun: Secara manual menggabungkan kod ke cawangan utama dan menyelesaikan sebarang konflik gabungan (jika berlaku).

Ujian asap menjimatkan banyak masa untuk pemaju yang akan menjalani ulasan kod dan jurutera ujian yang perlu mengulangi ciri A pada cawangan permintaan tarik. Sekiranya ujian asap pada permintaan tarik gagal, maka pemaju yang bertanggungjawab untuk fungsi A kini bertanggungjawab untuk menetapkan ciri ujian asap dan mengeluarkan permintaan tarik baru (sehingga masalah itu ditetapkan, kod bermasalah tidak akan digabungkan ke cawangan utama ).

Jika ini dilakukan, dan kod baru untuk fungsi A digabungkan ke cawangan utama dari perspektif CI, yang berikut akan berlaku:

ini menunjukkan bahawa gabungan itu berjaya, fungsi ujian asap masih sah, dan sekarang ia adalah tanggungjawab jurutera ujian untuk menguji semula ciri -ciri di cawangan utama sekali lagi (untuk memastikan gabungan itu tidak mempunyai kesan sampingan pada ciri a). Sudah tentu, ia adalah tabiat yang baik untuk meningkatkan suite automasi ujian dari masa ke masa untuk menampung kebanyakan ciri.

Ini menjadi semakin penting dalam lelaran akhir projek, kerana jurutera ujian mempunyai lebih banyak tugas (menguji ciri -ciri semasa dan semua ciri sebelumnya). Di sinilah ujian regresi berguna: dari perspektif CI, pelaksanaan ujian regresi biasanya berlaku apabila jurutera ujian secara eksplisit menjalankan ujian regresi atau ketika menggunakan penjadual (contohnya: melakukan ujian regresi setiap malam). Adalah kebiasaan yang baik untuk menyesuaikan pekerjaan ini supaya kami dapat menentukan cawangan mana yang akan dilakukan untuk dilakukan (di sini anda boleh membaca lebih lanjut mengenai mengapa dan kapan untuk melakukan automasi ujian regresi). Prosesnya adalah seperti berikut:

Pengenalan kepada Jenkins Tools

terminologi pelayan Jenkins CI

Kerja rumah: "Unit" yang paling penting dalam terminologi Jenkins adalah kerja rumah. Pekerjaan adalah unit pelaksanaan tunggal dalam pelayan Jenkins CI dan mesti mempunyai hasil tertentu (lulus/gagal). Sebagai contoh: Pekerjaan boleh menjadi pekerjaan penempatan, pekerjaan ujian asap, pekerjaan ujian regresi, dll. Pekerjaan terdiri daripada pelbagai bidang yang dilaksanakan secara urutan, yang akan dijelaskan dalam perenggan seterusnya: struktur pekerjaan Jenkins.

Plugin: Salah satu ciri utama Jenkins Test Automation adalah keupayaan untuk menyesuaikannya dengan menggunakan plugin sedia ada atau membuat plugin anda sendiri. Segala-galanya dalam alat Jenkins, dari bahagian Konfigurasi Kerja ke bahagian Konfigurasi Jenkins, sebenarnya adalah pemalam. Oleh kerana saiz besar komuniti Jenkins, pelbagai plugin Jenkins sudah wujud untuk memenuhi keperluan tugas aliran kerja CI yang paling menuntut. Ini bermakna anda kemungkinan besar akan menemui plugin yang berguna dan bukannya membuat penyelesaian tersuai.

Node: Dalam persediaan yang paling mudah, contoh Jenkins akan dijalankan pada mesin, di mana semua pekerjaan akan dilaksanakan. Untuk ujian kecil dan sedikit tugasan, ini masuk akal. Walau bagaimanapun, dalam praktiknya, sering terdapat kes di mana beberapa pasukan menggunakan contoh Jenkins yang sama. Oleh kerana mereka mempunyai sejumlah besar pekerjaan, ia dianggap tidak baik untuk dilaksanakan atas alasan untuk alasan berikut: keselamatan, pemulihan bencana, prestasi, skalabilitas, dll.

Masukkan Master/Hamba di Jenkins: Jenkins Master Node hanya digunakan untuk menjadualkan pekerjaan untuk dilaksanakan pada hamba Jenkins. Dengan cara ini, tuan rumah Jenkins tidak banyak digunakan, dan pasukan mempunyai mesin hamba sendiri yang merupakan saiz terbaik untuk projek automasi ujian mereka. Selain itu, nod hamba kemudian dikonfigurasikan untuk memproses beberapa pekerjaan selari yang akan dilaksanakan (bilangan pelaksana setiap nod). Anda juga boleh mengkonfigurasi nod atas permintaan dari AWS. Ini bermakna nod hanya wujud apabila pekerjaan perlu dilaksanakan di atasnya. Ini sangat berguna kerana kami mahukan mesin yang lebih besar yang hanya akan digunakan sepenuhnya apabila menjalankan ujian regresi. Untuk kes ini, contoh EC2 yang lebih besar akan dilancarkan pada AWS di mana tugas itu akan dilaksanakan dan setelah selesai (berdasarkan masa terbiar konfigurasi), contohnya akan tetap aktif untuk tempoh masa. Selepas itu, ia akan menentukan pendekatan mana yang lebih berfaedah apabila menggunakan perkhidmatan berbayar setiap jam, seperti perkhidmatan AWS.

Struktur Jenkins Job

Dalam pelayan Jenkins CI, setiap pekerjaan Jenkins mengandungi pelbagai bahagian:

• Umum: Di sini, kami menentukan projek/nama/keterangan kerja, tambahkan parameter pekerjaan yang diperlukan, tentukan strategi putaran log kerja, dll. Skrin seterusnya menunjukkan cara mengkonfigurasi putaran log (anda boleh menentukan bilangan hari untuk menyimpan log binaan atau bilangan log binaan terakhir yang akan disimpan), bagaimana untuk memarameterkan pekerjaan (dengan menambahkan rentetan binaan dengan nilai lalai 0.0.1, bagaimanapun, nilai ini boleh ditentukan semasa memulakan pekerjaan) dan bagaimana untuk mengkonfigurasi tempat kerja ini akan dilaksanakan (nama nod hamba):

  

  

Pengurusan Kod Sumber Jenkins: Seperti namanya, ini adalah di mana kita menentukan repositori kod sumber (seperti GitHub atau subversi) dalam pelayan Jenkins CI:

• 

  Jenkins Membina Pencetus: Jadualkan Masa Pelaksanaan Kerja (secara berkala, selepas pekerjaan lain, apabila permintaan tarik github berlaku, apabila perubahan ditolak ke GitHub, dll.).

• Jenkins Membina Alam Sekitar: Di sini kita menentukan pilihan yang berkaitan dengan persekitaran yang dibina akan dilaksanakan (padamkan ruang kerja setiap kali kerja dilaksanakan, membatalkan pekerjaan jika ia digantung untuk tempoh masa ... dll.).

  

• Jenkins Build: Dalam pelayan Jenkins CI, ini adalah langkah yang paling penting untuk setiap pekerjaan. Hasil dari langkah ini mempengaruhi status pekerjaan pada akhir pelaksanaan. Bergantung pada pemalam yang dipasang, banyak pilihan tersedia, plug-in yang paling biasa digunakan adalah: melaksanakan shell, melaksanakan skrip groovy, memanggil skrip Ant/Maven/Gradle, melaksanakan perintah batch Windows, dll.

  Ini adalah contoh plugin "melaksanakan shell" yang sering digunakan untuk menyamakan skrip shell anda sendiri atau melaksanakan skrip shell sedia ada.

Jenkins Post-Build Operasi: Bahagian kerja ini digunakan untuk melaporkan hasil kerja atau memanggil pekerjaan lain di saluran paip Jenkins. Secara umumnya, kami boleh menghantar e -mel yang mengandungi status pelaksanaan pekerjaan, menerbitkan laporan HTML, hasil Junit, menerbitkan artifak yang dibina di peringkat binaan ke S3, dll.

• Sila ambil perhatian bagaimana $ BUILD_ID ditentukan dalam baris subjek e -mel. Oleh kerana tugas ini parameter, nilai ini ditentukan apabila tugas dimulakan. Parameter ini boleh digunakan di bahagian operasi Build dan selepas membina Jenkins pekerjaan.

  Kesimpulan

Setakat ini, anda telah mempelajari manfaat utama pelayan Jenkins CI dan bagaimana CI sendiri ditambah kepada proses pembangunan perisian dan kepada jurutera ujian. Seperti mana -mana teknologi lain, ia mengambil masa untuk menguasai asas -asas dan mengalami kelebihan. Saya sangat mengesyorkan bahawa anda melabur masa anda di CI, yang pasti bernilai dalam jangka masa panjang. Khususnya, apabila pelayan Jenkins CI digunakan, banyak proses yang menyakitkan dan berulang -ulang akan automatik dan anda akan tiba -tiba mempunyai lebih banyak masa untuk memberi tumpuan kepada penambahbaikan produk.

Adakah pasukan anda juga melaksanakan integrasi berterusan dan pelayan Jenkins CI? Jangan ragu untuk berkongsi pengalaman pasukan anda dan bertanya soalan dalam komen!

Artikel ini pada asalnya diterbitkan di TestProject - Blog Automasi Ujian

---

Soalan Lazim Mengenai Integrasi Berterusan dengan Pelayan Jenkins CI

Apakah perbezaan utama antara Jenkins dan Travis CI?

Jenkins dan Travis CI adalah alat integrasi berterusan yang popular, tetapi mereka mempunyai beberapa perbezaan utama. Jenkins adalah penyelesaian yang dihoskan sendiri yang memerlukan anda mengurus dan mengekalkan pelayan anda sendiri. Ia sangat disesuaikan dan boleh dikonfigurasikan untuk menampung hampir mana -mana alur kerja CI/CD. Travis CI, sebaliknya, adalah perkhidmatan berasaskan awan yang mudah ditubuhkan dan digunakan. Ia mengintegrasikan dengan baik dengan GitHub dan menyokong banyak bahasa dari kotak. Walau bagaimanapun, untuk aliran kerja yang kompleks, ia mungkin tidak fleksibel seperti Jenkins.

Bagaimana Jenkins dibandingkan dengan Gitlab CI/CD?

Jenkins dan Gitlab CI/CD kedua -duanya menawarkan penyelesaian integrasi berterusan yang kuat. Jenkins terkenal dengan fleksibiliti dan ekosistem plugin yang besar, sementara Gitlab CI/CD telah menerima pujian untuk integrasi lancarnya dengan ekosistem Gitlab. Gitlab CI/CD juga menyediakan sokongan Docker terbina dalam, yang boleh menjadi kelebihan besar bagi pasukan menggunakan Docker.

Apakah kelebihan menggunakan Jenkins dan bukannya pelayan CI yang lain?

Jenkins menawarkan beberapa kelebihan ke atas pelayan CI yang lain. Ia adalah sumber terbuka dan mempunyai komuniti yang besar dan aktif, yang bermaksud ia sentiasa bertambah baik dan mengemas kini. Ia juga mempunyai ekosistem besar pemalam yang membolehkan anda memperluaskan keupayaannya untuk memenuhi keperluan khusus anda. Di samping itu, Jenkins menyokong pelbagai bahasa dan alat, menjadikannya pilihan yang sama untuk pelbagai projek.

Bagaimanakah Jenkins mengendalikan integrasi berterusan projek Python?

Jenkins adalah alat sejagat yang mengendalikan integrasi berterusan projek Python. Ia mengautomasikan pembinaan, ujian, dan penggunaan aplikasi Python dan menyokong banyak rangka kerja ujian Python yang popular. Jenkins juga mengintegrasikan dengan baik dengan sistem kawalan versi seperti Git, menjadikannya mudah untuk disatukan ke dalam aliran kerja anda yang sedia ada.

Apakah pertimbangan utama ketika memilih antara Jenkins dan Travis CI?

Apabila memilih antara Jenkins dan Travis CI, anda harus mempertimbangkan faktor -faktor seperti kepakaran teknikal pasukan, kerumitan aliran kerja CI/CD anda, dan bajet. Jenkins memerlukan lebih banyak persediaan dan penyelenggaraan, tetapi menawarkan fleksibiliti dan kawalan yang lebih besar. Travis CI lebih mudah untuk ditubuhkan dan digunakan, tetapi mungkin tidak cukup fleksibel untuk aliran kerja yang kompleks. Ia juga merupakan perkhidmatan berbayar, dan Jenkins adalah sumber percuma dan terbuka.

Bagaimana Jenkins menyokong saluran paip CI/CD?

Jenkins menyokong saluran paip CI/CD dari integrasi dan ujian untuk digunakan dengan mengautomasikan semua fasa penghantaran kod. Ia membolehkan maklum balas yang berterusan kerana pemaju dapat dengan cepat mengenal pasti dan menyelesaikan masalah dalam kod mereka. Jenkins juga mengintegrasikan dengan pelbagai alat dalam ekosistem CI/CD, menjadikannya pilihan yang sama untuk melaksanakan saluran paip CI/CD.

Bolehkah Jenkins digunakan untuk projek yang tidak dihoskan di GitHub?

Ya, Jenkins boleh digunakan untuk projek yang tidak dihoskan di GitHub. Ia menyokong pelbagai sistem kawalan versi termasuk subversi, mercurial, dan perforce. Ini menjadikan Jenkins pilihan sejagat untuk pasukan menggunakan sistem kawalan versi yang berbeza.

Bagaimanakah Jenkins mengendalikan selari?

Jenkins mengendalikan binaan selari dengan memperuntukkan tugas antara pelbagai mesin atau pelaksana. Ini membolehkan masa membina lebih cepat dan penggunaan sumber yang lebih cekap. Anda boleh mengkonfigurasi Jenkins untuk mengurus infrastruktur membina anda secara automatik atau secara manual menentukan tugas -tugas yang harus dijalankan di mana mesin.

Apakah cabaran umum yang anda hadapi ketika menubuhkan Jenkins?

Beberapa cabaran biasa apabila menubuhkan Jenkins termasuk menguruskan kebergantungan, mengkonfigurasi pembentukan pencetus, dan menubuhkan akses yang selamat. Walau bagaimanapun, Jenkins mempunyai komuniti yang besar dan aktif, jadi terdapat banyak sumber untuk membantu anda mengatasi cabaran -cabaran ini.

Bagaimana untuk memperluaskan fungsi Jenkins?

anda boleh melanjutkan fungsi Jenkins dengan memasang plugin. Jenkins mempunyai ekosistem besar plugin yang termasuk plugin untuk pelbagai fungsi dari integrasi dengan sistem kawalan versi yang berbeza untuk meningkatkan antara muka pengguna. Jika anda memerlukan ciri -ciri yang tidak disediakan oleh plugin sedia ada, anda juga boleh menulis plugin anda sendiri.

Atas ialah kandungan terperinci Garis Panduan Utama untuk Integrasi Berterusan dan Jenkins CI Server. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!