Tutorial Pengiriman Berkelanjutan - Membangun Saluran Pengiriman Berkelanjutan Menggunakan Jenkins

Pengiriman Berkelanjutan:

Pengiriman Berkelanjutan adalah proses, di mana perubahan kode secara otomatis dibuat, diuji, dan disiapkan untuk rilis ke produksi.Saya harap Anda menikmati saya Di sini, saya akan berbicara tentang topik berikut:

• Apa itu Pengiriman Berkelanjutan?
• Jenis Pengujian Perangkat Lunak
• Perbedaan Antara Integrasi Berkelanjutan, Pengiriman, dan Penerapan
• Apa kebutuhan Pengiriman Berkelanjutan?
• Hands-on Menggunakan Jenkins dan Tomcat

Mari kita segera memahami cara kerja Pengiriman Berkelanjutan.

Apakah Pengiriman Berkelanjutan itu?

Ini adalah proses di mana Anda membangun perangkat lunak sedemikian rupa sehingga dapat dirilis ke produksi kapan saja.Perhatikan diagram di bawah ini:

Izinkan saya menjelaskan diagram di atas:

• Skrip build otomatis akan mendeteksi perubahan dalam Source Code Management (SCM) seperti Git.
• Setelah perubahan terdeteksi, kode sumber akan diterapkan ke server build khusus untuk memastikan build tidak gagal dan semua kelas pengujian serta pengujian integrasi berjalan dengan baik.
• Kemudian, aplikasi build digunakan di server uji (server praproduksi) untuk User Acceptance Test (UAT).
• Terakhir, aplikasi secara manual ditempatkan di server produksi untuk dirilis.

Sebelum saya melanjutkan, akan adil jika saya menjelaskan kepada Anda berbagai jenis pengujian.

Jenis Pengujian Perangkat Lunak:

Secara garis besar ada dua jenis pengujian:

• Pengujian Blackbox: Ini adalah teknik pengujian yang mengabaikan mekanisme internal sistem dan berfokus pada keluaran yang dihasilkan terhadap masukan dan pelaksanaan sistem. Ini juga disebut pengujian fungsional. Ini pada dasarnya digunakan untuk memvalidasi perangkat lunak.
• Pengujian Whitebox: adalah teknik pengujian yang memperhitungkan mekanisme internal suatu sistem. Ini juga disebut pengujian struktural dan pengujian kotak kaca. Ini pada dasarnya digunakan untuk memverifikasi perangkat lunak.

Pengujian Whitebox:

Ada dua jenis pengujian, yang termasuk dalam kategori ini.

• Pengujian Unit: Ini adalah pengujian unit individu atau kelompok unit terkait. Hal ini sering dilakukan oleh programmer untuk menguji bahwa unit yang dia implementasikan menghasilkan output yang diharapkan terhadap input yang diberikan.
• Tes integrasi: Ini adalah jenis pengujian di mana sekelompok komponen beradadigabungkan untuk menghasilkan keluaran. Selain itu, interaksi antara perangkat lunak dan perangkat keras diuji jika komponen perangkat lunak dan perangkat keras memiliki hubungan apa pun. Ini mungkin termasuk dalam pengujian kotak putih dan pengujian kotak hitam.

Pengujian Blackbox:

Ada beberapa tes yang termasuk dalam kategori ini. Saya akan fokus padaBeberapa, yang penting untuk Anda ketahui, untuk memahami blog ini:

struktur data dan algoritma java

• Pengujian Fungsional / Penerimaan: Ini memastikan bahwa fungsionalitas yang ditentukan yang diperlukan dalam persyaratan sistem berfungsi. Hal ini dilakukan untuk memastikan bahwa produk yang dikirim memenuhi persyaratan dan berfungsi sesuai harapan pelanggan
• Pengujian Sistem: Ini memastikan bahwa dengan meletakkan perangkat lunak di lingkungan yang berbeda (mis., Sistem Operasi) itu masih berfungsi.
• Pengujian Stres: Ini mengevaluasi bagaimana sistem berperilaku dalam kondisi yang tidak menguntungkan.
• Pengujian Beta: Ini dilakukan oleh pengguna akhir, tim di luar pengembangan, atau secara publik merilis versi lengkap dari produk yang dikenal sebagaibetaVersi: kapan. Tujuan pengujian beta adalah untuk menutupi kesalahan yang tidak terduga.

Sekarang adalah waktu yang tepat bagi saya untuk menjelaskan perbedaan antara Continuous Integration, Delivery, dan Deployment.

Perbedaan Antara Integrasi Berkelanjutan, Pengiriman, dan Penerapan:

Konten visual mencapai otak individu dengan cara yang lebih cepat dan lebih mudah dipahami daripada informasi tekstual. Jadi saya akan mulai dengan diagram yang menjelaskan perbedaannya dengan jelas:

Dalam Continuous Integration, setiap kode komit dibangun dan diuji, tetapi tidak dalam kondisi untuk dirilis. Maksud saya, aplikasi build tidak secara otomatis digunakan di server pengujian untuk memvalidasinya menggunakan berbagai jenis pengujian Blackbox seperti - Pengujian Penerimaan Pengguna (UAT).

Dalam Pengiriman Berkelanjutan, aplikasi terus digunakan di server uji untuk UAT. Atau, bisa dibilang aplikasinya siap dirilis ke produksi kapan saja. Jadi, Integrasi Berkelanjutan jelas diperlukan untuk Pengiriman Berkelanjutan.

Continuous Deployment adalah langkah selanjutnya setelah Continuous Delivery, di mana Anda tidak hanya membuat paket yang dapat diterapkan, tetapi sebenarnya Anda menerapkannya secara otomatis.

Izinkan saya meringkas perbedaan menggunakan tabel:

Secara sederhana, Integrasi Berkelanjutan adalah bagian dari Pengiriman Berkelanjutan dan Penerapan Berkelanjutan. Dan Penerapan Berkelanjutan seperti Pengiriman Berkelanjutan, kecuali bahwa rilis terjadi secara otomatis.

Pelajari Cara Membuat Pipeline CI / CD Menggunakan Jenkins On Cloud

Namun pertanyaannya adalah, apakah Continuous Integration sudah cukup.

Mengapa Kami Membutuhkan Pengiriman Berkelanjutan?

Mari kita pahami ini dengan sebuah contoh.

Bayangkan ada 80 developer yang mengerjakan sebuah proyek besar. Mereka menggunakan pipeline Integrasi Berkelanjutan untuk memfasilitasi build otomatis. Kami tahu bahwa build juga menyertakan Pengujian Unit. Suatu hari mereka memutuskan untuk menerapkan versi terbaru yang telah lulus pengujian unit ke dalam lingkungan pengujian.

Ini harus menjadi pendekatan yang panjang namun terkontrol untuk penyebaran yang dilakukan oleh spesialis lingkungan mereka. Namun, tampaknya sistem tersebut tidak berfungsi.

Apa Yang Mungkin Menjadi Penyebab Kegagalan yang Jelas?

Nah, alasan pertama yang kebanyakan orang akan pikirkan adalah ada beberapa masalah dengan konfigurasi. Seperti kebanyakan orang bahkan mereka berpikir demikian.Mereka menghabiskan banyak waktu untuk menemukan apa yang salah dengan konfigurasi lingkungan, tetapi mereka tidak dapat menemukan masalahnya.

Satu Pengembang Perseptif Mengambil Pendekatan Cerdas:

Kemudian salah satu Pengembang senior mencoba aplikasi tersebut di mesin pengembangannya. Itu juga tidak berhasil di sana.

Dia melangkah mundur melalui versi sebelumnya dan sebelumnya sampai dia menemukan bahwa sistem telah berhenti bekerja tiga minggu sebelumnya. Bug kecil dan tidak jelas telah mencegah sistem untuk memulai dengan benar. Meskipun, proyek tersebut memiliki cakupan pengujian unit yang baik.Meskipun demikian, 80 pengembang, yang biasanya hanya menjalankan tes daripada aplikasinya sendiri, tidak melihat masalah selama tiga minggu.

Pernyataan masalah:

Tanpa menjalankan Uji Penerimaan dalam lingkungan seperti produksi, mereka tidak tahu apa-apa tentang apakah aplikasi memenuhi spesifikasi pelanggan, atau apakah dapat diterapkan dan bertahan di dunia nyata. Jika mereka menginginkan umpan balik yang tepat waktu tentang topik ini, mereka harus memperluas jangkauan proses integrasi berkelanjutan mereka.

Izinkan saya meringkas pelajaran yang diperoleh dengan melihat masalah di atas:

• Pengujian Unit hanya menguji perspektif pengembang dari solusi untuk suatu masalah. Mereka hanya memiliki kemampuan terbatas untuk membuktikan bahwa aplikasi melakukan apa yang seharusnya dari perspektif pengguna. Mereka tidak cukup untukmengidentifikasi masalah fungsional yang sebenarnya.
• Menerapkan aplikasi di lingkungan pengujian adalah proses yang rumit dan intensif secara manual yang cukup rentan terhadap kesalahan.Ini berarti bahwa setiap upaya penerapan adalah eksperimen baru - proses manual yang rawan kesalahan.

Solusi - Saluran Pengiriman Berkelanjutan (Tes Penerimaan Otomatis):

Mereka mengambil Integrasi Berkelanjutan (Pengiriman Berkelanjutan) ke langkah berikutnya dan memperkenalkan beberapa Pengujian Penerimaan otomatis sederhana yang membuktikan bahwa aplikasi berjalan dan dapat melakukan fungsi yang paling mendasar.Mayoritas tes yang dijalankan selama tahap Tes Penerimaan adalah Tes Penerimaan Fungsional.

Pada dasarnya, mereka membangun pipeline Pengiriman Berkelanjutan, untuk memastikan bahwa aplikasi diterapkan secara mulus di lingkungan produksi, dengan memastikan bahwa aplikasi berfungsi dengan baik saat diterapkan di server pengujian yang merupakan replika dari server produksi.

Cukup teorinya, sekarang saya akan menunjukkan cara membuat pipeline Pengiriman Berkelanjutan menggunakan Jenkins.

Saluran Pengiriman Berkelanjutan Menggunakan Jenkins:

Di sini saya akan menggunakan Jenkins untuk membuat Saluran Pengiriman Berkelanjutan, yang akan mencakup tugas-tugas berikut:

Langkah-langkah yang terlibat dalam Demo:

• Mengambil kode dari GitHub
• Menyusun kode sumber
• Pengujian unit dan pembuatan laporan pengujian JUnit
• Mengemas aplikasi ke dalam file WAR dan menerapkannya di server Tomcat

Prasyarat:

• Mesin CentOS 7
• Jenkins 2.121.1
• Buruh pelabuhan
• Tomcat 7

Langkah - 1 Menyusun Kode Sumber:

Mari kita mulai dengan membuat proyek Freestyle terlebih dahulu di Jenkins. Perhatikan tangkapan layar di bawah ini:

Beri nama untuk proyek Anda dan pilih Freestyle Project:

Ketika Anda menggulir ke bawah Anda akan menemukan opsi untuk menambahkan repositori kode sumber, pilih git dan tambahkan URL repositori, di repositori itu ada denda pom.xml yang akan kita gunakan untuk membangun proyek kita. Perhatikan tangkapan layar di bawah ini:

Sekarang kita akan menambahkan Build Trigger. Pilih opsi SCM polling, pada dasarnya, kami akan mengonfigurasi Jenkins untuk melakukan polling repositori GitHub setelah setiap 5 menit untuk perubahan kode. Perhatikan tangkapan layar di bawah ini:

Sebelum saya melanjutkan, izinkan saya memberi Anda sedikit pengantar tentang Siklus Pembuatan Maven.

Setiap siklus proses build ditentukan oleh daftar fase build yang berbeda, di mana fase build mewakili satu tahapan dalam siklus proses.

Berikut adalah daftar fase build:

• memvalidasi - memvalidasi proyek dengan benar dan semua informasi yang diperlukan tersedia
• kompilasi - kompilasi kode sumber proyek
• uji - uji kode sumber yang dikompilasi menggunakan kerangka pengujian unit yang sesuai. Tes ini tidak memerlukan kode untuk dikemas atau diterapkan
• paket - ambil kode yang telah dikompilasi dan paketkan dalam format yang dapat didistribusikan, seperti JAR.
• verifikasi - jalankan pemeriksaan apa pun pada hasil uji integrasi untuk memastikan kriteria kualitas terpenuhi
• install - instal paket ke dalam repositori lokal, untuk digunakan sebagai dependensi dalam proyek lain secara lokal
• deploy - selesai di lingkungan build, menyalin paket akhir ke repositori jarak jauh untuk dibagikan dengan developer dan project lain.

Saya dapat menjalankan perintah di bawah ini, untuk menyusun kode sumber, pengujian unit dan bahkan mengemas aplikasi dalam file perang:

paket bersih mvn

Anda juga dapat memecah pekerjaan build Anda menjadi beberapa langkah build. Ini membuatnya lebih mudah untuk mengatur bangunan dalam tahapan yang bersih dan terpisah.

Jadi kita akan mulai dengan menyusun kode sumber. Di tab build, klik panggil target maven tingkat atas dan ketik perintah di bawah ini:

menyusun

Perhatikan tangkapan layar di bawah ini:

Ini akan menarik kode sumber dari repositori GitHub dan juga akan mengkompilasinya (Fase Kompilasi Maven).

Klik Simpan dan jalankan proyek.

Sekarang, klik pada output konsol untuk melihat hasilnya.

Langkah - 2 Pengujian Unit:

Sekarang kita akan membuat satu Proyek Gaya Bebas lagi untuk pengujian unit.

Tambahkan URL repositori yang sama di tab manajemen kode sumber, seperti yang kita lakukan di pekerjaan sebelumnya.

Sekarang, di tab 'Buid Trigger' klik 'bangun setelah proyek lain dibangun'. Di sana ketik nama proyek sebelumnya tempat kami menyusun kode sumber, dan Anda dapat memilih salah satu opsi di bawah ini:

• Picu hanya jika build stabil
• Memicu meskipun build tidak stabil
• Memicu bahkan jika build gagal

Saya pikir opsi di atas cukup jelas jadi, pilih salah satu. Perhatikan tangkapan layar di bawah ini:

Di tab Build, klik panggil target maven tingkat atas dan gunakan perintah di bawah ini:

uji

Jenkins juga melakukan pekerjaan yang baik dalam membantu Anda menampilkan hasil tes dan tren hasil tes Anda.

Standar de facto untuk pelaporan pengujian di dunia Java adalah format XML yang digunakan oleh JUnit. Format ini juga digunakan oleh banyak alat pengujian Java lainnya, seperti TestNG, Spock, dan Easyb. Jenkins memahami format ini, jadi jika build Anda menghasilkan hasil pengujian XML JUnit, Jenkins dapat membuat laporan pengujian grafis dan statistik hasil pengujian yang bagus dari waktu ke waktu, dan juga memungkinkan Anda melihat detail kegagalan pengujian. Jenkins juga melacak berapa lama waktu yang dibutuhkan untuk menjalankan pengujian, baik secara global, dan per pengujian — ini bisa berguna jika Anda perlu melacak masalah performa.

Jadi, hal berikutnya yang perlu kita lakukan adalah membuat Jenkins mengawasi pengujian unit kita.

Buka bagian Tindakan Pasca-build dan centang kotak 'Publikasikan laporan hasil pengujian JUnit'. Saat Maven menjalankan pengujian unit dalam sebuah proyek, Maven secara otomatis menghasilkan laporan pengujian XML dalam direktori yang disebut laporan-pasti. Jadi, masukkan '** / target / surefire-reports / *. Xml' di bidang 'Uji XML laporan'. Dua tanda bintang di awal jalur (“**”) adalah praktik terbaik untuk membuat konfigurasi sedikit lebih kuat: keduanya memungkinkan Jenkins untuk menemukan direktori target tidak peduli bagaimana kami telah mengonfigurasi Jenkins untuk memeriksa kode sumber.

** / target / surefire-reports / *. xml

Sekali lagi simpan dan klik Build Now.

cara membuat sesi di java

Sekarang, laporan JUnit ditulis ke / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behaviour.

Di dasbor JenkinsAnda juga bisa melihat hasil tesnya:

Langkah - 3 Membuat File WAR dan Menerapkannya di Server Tomcat:

Sekarang, langkah selanjutnya adalah mengemas aplikasi kita dalam file WAR dan menerapkannya di server Tomcat untuk pengujian User Acceptance.

Buat satu proyek gaya bebas lagi dan tambahkan URL repositori kode sumber.

Kemudian di tab pemicu build, pilih build ketika proyek lain dibuat, pertimbangkan gambar di bawah ini:

Pada dasarnya, setelah pekerjaan pengujian, fase penerapan akan dimulai secara otomatis.

Di tab build, pilih skrip shell. Ketik perintah di bawah ini untuk mengemas aplikasi dalam file WAR:

paket mvn

Langkah selanjutnya adalah menyebarkan file WAR ini ke Tomcatserver. Di tab 'Tindakan Pasca-Bangun' pilih terapkan perang / telinga ke penampung. Di sini, berikan jalur ke file perang dan berikan jalur konteksnya. Perhatikan tangkapan layar di bawah ini:

Pilih kredensial Tomcat dan, perhatikan tangkapan layar di atas. Selain itu, Anda perlu memberikan URL server Tomcat Anda.

Untuk menambahkan kredensial di Jenkins, klik opsi kredensial di dasbor Jenkins.

Klik Sistem dan pilih kredensial global.

Kemudian Anda akan menemukan opsi untuk menambahkan kredensial. Klik di atasnya dan tambahkan kredensial.

Tambahkan kredensial Tomcat, pertimbangkan gambar di bawah ini.

Klik OK.

Sekarang di Konfigurasi Proyek Anda, tambahkan kredensial tomcat yang telah Anda masukkan pada langkah sebelumnya.

Klik Save dan kemudian pilih Build Now.

Buka URL kucing jantan Anda, dengan jalur konteks, dalam kasus saya adalah http: // localhost: 8081. Sekarang tambahkan jalur konteks pada akhirnya, pertimbangkan Screenshot di bawah ini:

Tautan - http: // localhost: 8081 / gof

Saya harap Anda telah memahami arti dari jalur konteks.

Sekarang buat tampilan pipeline, perhatikan screenshot di bawah ini:

Klik pada ikon plus, untuk membuat tampilan baru.

Konfigurasi pipeline seperti yang Anda inginkan, pertimbangkan screenshot di bawah ini:

Saya tidak mengubah apa pun selain memilih pekerjaan awal. Jadi pipeline saya akan mulai dari kompilasi. Berdasarkan cara saya mengonfigurasi pekerjaan lain, setelah kompilasi pengujian dan penerapan akan terjadi.

Terakhir, Anda dapat menguji pipeline dengan mengklik RUN. Setelah setiap lima menit, jika ada perubahan pada kode sumber, seluruh pipeline akan dijalankan.

dimana variabel instance harus dideklarasikan di java

Jadi kami dapat terus menerapkan aplikasi kami di server uji untuk uji penerimaan pengguna (UAT).

Saya harap Anda menikmati membaca posting ini tentang Pengiriman Berkelanjutan. Jika Anda memiliki keraguan, silakan letakkan di bagian komentar di bawah ini dan saya akan membalasnya paling awal.

Untuk Membangun Pipa CI / CD Anda Perlu Menguasai Berbagai Keterampilan Kuasai Keterampilan DevOps yang Dibutuhkan Sekarang