Memahami Integrasi Berkelanjutan dan Penerapan Berkelanjutan

Mendengar CI / CD tetapi tidak yakin apa itu?


Idealnya, insinyur perangkat lunak disewa untuk menulis kode yang perlu dikirim ke lingkungan produksi sehingga bisnis yang membutuhkan produk dapat memanfaatkannya. Untuk memuaskan bisnis (sering disebut pengguna / klien), penting bahwa produknya bebas bug.

Pendekatan umum yang diikuti oleh insinyur perangkat lunak adalah bekerja di cabang dan membuat permintaan tarik yang memperbarui cabang utama dengan pembaruan baru yang telah dibuat. Kami telah mengadopsi praktik tes menulis sebagai cara untuk memastikan bahwa perubahan baru tidak menimbulkan bug. Ketika pengembang mengerjakan fitur dalam kebanyakan kasus, mereka sering tidak membuat permintaan tarik sampai mereka benar-benar selesai dengan fitur tersebut. Apa yang terjadi ketika mereka siap adalah itu;

  • Mereka menghabiskan banyak waktu untuk mencoba memperbarui basis kode dengan perubahan yang telah terjadi di cabang produksi saat mereka bekerja.
  • Dalam melakukan itu, mereka harus memperbaiki serangkaian konflik penggabungan.
  • Ada juga kemungkinan mereka melanggar cabang produksi, yang selanjutnya mempengaruhi mereka yang menarik dari cabang sebelum masalah terlihat dan diperbaiki.

Jika Anda pernah berada dalam situasi ini, Anda akan setuju bahwa itu bisa menyebalkan – tidak ada yang mau menghabiskan hari kerja mereka seperti ini.

Apa solusinya?

Integrasi berkelanjutan

https://www.youtube.com/watch?v=HnWuIjUw_Q8

Untuk mencegah skenario yang saya nyatakan di atas; tim teknik dapat mengadopsi praktik yang disebut integrasi berkelanjutan – seperti namanya, ini melibatkan integrasi terus menerus dari perubahan kode yang dibuat oleh pengembang ke cabang / repositori bersama. Kode yang akan diintegrasikan harus menjalani tes yang diverifikasi untuk memastikan tidak merusak aplikasi. Hanya ketika tes lulus maka itu terintegrasi

Untuk memahami ini, mari kita bayangkan skenario kehidupan nyata di mana ada tim 10 pengembang. Pengembang ini membuat cabang secara lokal di mana mereka menulis kode untuk implementasi fitur-fitur tertentu. Alih-alih mengirim permintaan tarik ketika mereka sepenuhnya selesai dengan fitur, mereka memilih untuk mengirim permintaan tarik karena mereka membuat sedikit perubahan. Contoh dari perubahan tersebut adalah penciptaan modal baru, dengan asumsi pengembang sedang mengerjakan fitur yang memungkinkan pengguna untuk mengelola tugas individu dalam aplikasi. Alih-alih menunggu hingga fitur tugas selesai, untuk mematuhi pola integrasi berkelanjutan, pengembang mendorong perubahan kecil ini (bila dibandingkan dengan apa yang sedang dikerjakannya) dan membuat permintaan tarik untuk bergabung ke kode.

Sebelum perubahan baru ini diintegrasikan, serangkaian tes harus dijalankan.

Tim rekayasa perangkat lunak memanfaatkan alat-alat seperti Travis CI untuk membuat proses dan tes integrasi ini. Dengan alat-alat seperti ini, tes otomatis, sehingga berjalan segera setelah permintaan tarik diajukan ke cabang target yang dipilih selama pengaturan.

Hasil tes dihasilkan, dan pengembang yang membuat permintaan tarikan dapat melihat hasilnya dan membuat perubahan yang diperlukan. Manfaat dari berpegang pada pola ini mengintegrasikan kode sesedikit mungkin, dan memiliki tes terverifikasi untuk dijalankan adalah;

  • Menjadi mungkin bagi tim yang terlibat untuk mengetahui apa yang menyebabkan proses pembangunan atau pengujian gagal. Ini mengurangi kemungkinan pengiriman bug ke produksi.
  • Jika tim mengotomatiskan prosesnya, mereka akan memiliki waktu luang untuk fokus menjadi produktif.

Hal penting yang perlu diperhatikan dalam praktik ini adalah mendorong tim untuk sering mendorong kode ke cabang utama. Melakukan ini tidak akan efektif jika anggota lain dari tim tidak menarik dari cabang utama untuk memperbarui repositori lokal mereka.

Jenis tes

Dalam menulis tes yang akan menjadi bagian dari proses integrasi, berikut adalah beberapa yang dapat diimplementasikan dalam proses:

  • Integrasi – ini menggabungkan unit individual dari perangkat lunak dan mengujinya sebagai sebuah kelompok.
  • Unit – ini menguji unit individual atau komponen perangkat lunak seperti metode atau fungsi.
  • UI – menegaskan bahwa perangkat lunak berfungsi dengan baik dari perspektif pengguna.
  • Penerimaan – menguji bahwa perangkat lunak memenuhi persyaratan bisnis.

Penting untuk dicatat bahwa Anda tidak perlu menguji semua ini, karena beberapa dari mereka mungkin sudah tercakup dalam kode yang ditulis oleh pengembang.

Alat Integrasi Berkelanjutan

Tanpa masuk lebih dalam, berikut adalah alat yang dapat Anda gunakan dalam proyek Anda saat ini atau yang baru;

  • Travis CI – Dikenal di dunia open-source dan berjanji kepada Anda untuk menguji kode Anda dalam beberapa menit.
  • Lingkari CI – memberi Anda kekuatan, fleksibilitas, dan kontrol untuk mengotomatiskan pipa Anda dari kontrol ke penyebaran.
  • Jenkins – menyediakan ratusan plugin untuk mendukung membangun, menyebarkan, dan mengotomatisasi proyek apa pun.

Jika Anda baru di Jenkins maka saya sarankan mengambil ini Udemy tentu saja untuk belajar CI dengan Java dan .NET.

Penerapan berkelanjutan

Apa gunanya itu jika fitur yang Anda bangun duduk di repositori selama berminggu-minggu atau berbulan-bulan sebelum digunakan untuk lingkungan produksi. Sebanyak tim teknik dapat berupaya mengintegrasikan perubahan kecil ke cabang utama saat itu terjadi, mereka juga dapat mendorong perubahan ini ke lingkungan produksi sesegera mungkin.

Tujuan ketika mempraktikkan penerapan berkelanjutan adalah untuk mendapatkan perubahan yang dibuat kepada pengguna segera setelah pengembang mengintegrasikan perubahan ini di cabang utama.

Seperti dalam kasus integrasi berkelanjutan, ketika menggunakan penyebaran berkelanjutan, pengujian dan pemeriksaan otomatis dilakukan untuk memastikan bahwa perubahan yang baru terintegrasi diverifikasi. Penempatan hanya terjadi ketika tes ini berlalu.

Agar sebuah tim mendapat manfaat dari praktik penyebaran yang berkelanjutan, mereka perlu memiliki yang berikut;

  • Pengujian otomatis adalah tulang punggung penting dari semua praktik rekayasa berkelanjutan. Dalam kasus penyebaran berkelanjutan, kode yang akan digunakan harus memenuhi standar yang telah ditetapkan oleh tim untuk apa yang ingin mereka sampaikan kepada pengguna akhir. Idealnya, jika perubahan baru di bawah ambang batas, tes harus gagal dan tidak terintegrasi. Selain itu, ia menjadi terintegrasi.
  • Meskipun memiliki tes otomatis back-to-back, ada kemungkinan beberapa bug akan masuk ke lingkungan produksi. Untuk ini, perlu bahwa tim dapat membatalkan perubahan yang telah dibuat – membatalkan penyebaran. Ini harus mengembalikan kode produksi menjadi seperti sebelum perubahan baru dibuat.
  • Sistem pemantauan diperlukan untuk melacak perubahan yang telah didorong ke lingkungan produksi. Ini adalah bagaimana tim dapat melacak bug yang ditemui pengguna saat memanfaatkan perubahan yang digunakan.

Alat yang disebutkan untuk integrasi berkelanjutan juga memberi Anda fungsionalitas untuk mengatur sistem penerapan berkelanjutan. Ada banyak di antaranya yang bisa Anda baca.

Kesimpulan

Produktivitas tim pengembangan sangat penting untuk keberhasilan bisnis. Untuk memastikan mereka produktif, praktik yang mendorong ini harus diadopsi. Integrasi dan penyebaran berkelanjutan adalah contoh dari praktik tersebut.

Dengan integrasi berkelanjutan, tim dapat mendorong sebanyak mungkin kode setiap hari. Dengan ini tercapai, menjadi mudah untuk menyebarkan perubahan yang baru ditambahkan ke pengguna sesegera mungkin. Menyebarkan perubahan ini memungkinkan untuk mendapatkan umpan balik dari pengguna. Pada akhirnya, bisnis akan dapat berinovasi berdasarkan umpan balik yang diterima, yang merupakan win-win untuk semua orang.

Jika Anda seorang pengembang dan tertarik untuk mempelajari CI / CD, periksa ini tentu saja brilian.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map