Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Bagaimana CI/CD proses sepenuhnya berbeda
Pipa CI/CD menggunakan *alur kerja berbasis batang* modern, di mana pengembang menggabungkan pembaruan kecil dan sering ke cabang utama (atau *trunk*) yang dibangun dan diuji melalui bagian CD dari pipa. CI/CD Alur kerja ini telah menggantikan *alur kerja Gitflow*, di mana cabang pengembangan dan rilis dipisahkan oleh jadwal rilis. Di banyak organisasi, Gitflow masih merupakan metode kontrol dan penyebaran versi yang populer. Namun, sekarang dianggap warisan, dan dapat menjadi tantangan untuk diintegrasikan ke dalam CI/CD pipa.
Bagi banyak organisasi, transisi dari alur kerja Gitflow ke alur kerja berbasis batang tidak lengkap, dan hasilnya adalah mereka terjebak di suatu tempat di sepanjang jalan dan tidak pernah sepenuhnya bermigrasi ke CI/CD. Entah bagaimana, jaringan pipa mereka akhirnya menempel pada sisa-sisa tertentu dari alur kerja warisan, terjebak dalam keadaan transisi antara masa lalu dan sekarang. Tinjau perbedaan dalam alur kerja Git, lalu pelajari cara menggunakan alur kerja lama dapat memengaruhi hal-hal berikut:
+ [Integritas lingkungan](environment-integrity.md)
+ [Rilis](releases.md)
+ [Keamanan](security.md)
[Untuk mempermudah mengidentifikasi sisa-sisa alur kerja Git lama dalam konfigurasi modern, mari kita [bandingkan](#gitflow-approach) Gitflow dengan pendekatan modern berbasis batang.](#trunk-based-approach)
## Pendekatan Gitflow
Gambar berikut menunjukkan alur kerja Gitflow. Pendekatan Gitflow menggunakan beberapa cabang untuk melacak beberapa versi kode yang berbeda secara bersamaan. Anda menjadwalkan rilis pembaruan ke aplikasi untuk beberapa titik di masa mendatang sementara pengembang masih mengerjakan versi kode saat ini. Repositori berbasis Trunk dapat menggunakan flag fitur untuk mencapai ini, tetapi itu dibangun ke Gitflow secara default.
![\[Alur kerja Gitflow dengan cabang fitur, pengembangan, rilis, dan perbaikan terbaru\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)
Salah satu hasil dari pendekatan Gitflow adalah bahwa lingkungan aplikasi biasanya tidak sinkron. Dalam implementasi Gitflow standar, lingkungan pengembangan mencerminkan status kode saat ini sementara lingkungan praproduksi dan produksi tetap beku pada status basis kode dari rilis terbaru.
Ini memperumit hal-hal ketika cacat muncul di lingkungan produksi karena basis kode tempat pengembang bekerja tidak dapat digabungkan ke dalam produksi tanpa mengekspos fitur yang belum dirilis. Cara Gitflow menangani situasi ini adalah dengan menggunakan perbaikan terbaru. Cabang hotfix dibuat dari cabang rilis dan kemudian diterapkan langsung ke lingkungan atas. Cabang hotfix kemudian digabungkan ke dalam cabang pengembangan untuk menjaga kode tetap terkini.
## Pendekatan berbasis batang
Gambar berikut menunjukkan alur kerja berbasis batang. Dalam alur kerja berbasis batang, pengembang membangun dan menguji fitur secara lokal di cabang fitur dan kemudian menggabungkan perubahan tersebut ke cabang utama. Cabang utama kemudian dibangun untuk pengembangan, praproduksi, dan lingkungan produksi, secara berurutan. Tes unit dan integrasi terjadi antara setiap lingkungan.
![\[Alur kerja berbasis batang dengan cabang fitur dan cabang utama.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)
Menggunakan alur kerja ini, semua lingkungan mengoperasikan basis kode yang sama. Tidak perlu cabang perbaikan terbaru untuk lingkungan atas karena Anda dapat menerapkan perubahan di cabang utama tanpa mengekspos fitur yang belum dirilis. Cabang utama selalu dianggap stabil, bebas dari cacat, dan siap dilepaskan. Ini membantu Anda mengintegrasikannya sebagai sumber untuk CI/CD pipeline, yang dapat secara otomatis menguji dan menerapkan basis kode Anda melalui semua lingkungan di pipeline Anda.
# Manfaat integritas lingkungan dari pendekatan berbasis batang
Seperti yang diketahui banyak pengembang, satu perubahan kode terkadang dapat menciptakan [efek kupu-kupu](https://www.americanscientist.org/article/understanding-the-butterfly-effect) (artikel American Scientist), di mana penyimpangan kecil yang tampaknya tidak terkait memicu reaksi berantai yang menyebabkan hasil yang tidak terduga. Pengembang kemudian harus menyelidiki sepenuhnya untuk menemukan akar masalahnya.
Ketika para ilmuwan melakukan percobaan, mereka memisahkan subjek uji menjadi dua kelompok: kelompok eksperimen dan kelompok kontrol. Tujuannya adalah untuk membuat kelompok eksperimen dan kelompok kontrol benar-benar identik kecuali untuk hal yang diuji dalam percobaan. Ketika sesuatu terjadi pada kelompok eksperimen yang tidak terjadi pada kelompok kontrol, satu-satunya penyebab adalah hal yang sedang diuji.
Pikirkan perubahan dalam penyebaran sebagai kelompok eksperimen, dan pikirkan setiap lingkungan sebagai kelompok kontrol yang terpisah. Hasil pengujian di lingkungan yang lebih rendah hanya dapat diandalkan ketika kontrolnya sama dengan di lingkungan atas. Semakin banyak lingkungan menyimpang, semakin besar peluang untuk menemukan cacat di lingkungan atas. Dengan kata lain, jika perubahan kode akan gagal dalam produksi, kami lebih suka mereka gagal dalam versi beta terlebih dahulu sehingga tidak pernah sampai ke produksi. Inilah sebabnya mengapa setiap upaya harus dilakukan untuk menjaga setiap lingkungan, dari lingkungan pengujian terendah hingga produksi itu sendiri, sinkron. Ini disebut *integritas lingkungan*.
Tujuan dari setiap CI/CD proses sepenuhnya adalah untuk menemukan masalah sedini mungkin. Melestarikan integritas lingkungan dengan menggunakan pendekatan berbasis batang hampir dapat menghilangkan kebutuhan akan perbaikan terbaru. Dalam alur kerja berbasis batang, jarang masalah muncul pertama kali di lingkungan produksi.
Dalam pendekatan Gitflow, setelah hotfix diterapkan langsung ke lingkungan atas, kemudian ditambahkan ke cabang pengembangan. Ini mempertahankan perbaikan untuk rilis future. Namun, perbaikan terbaru dikembangkan dan diuji langsung dari keadaan aplikasi saat ini. Bahkan jika perbaikan terbaru bekerja dengan sempurna dalam produksi, ada kemungkinan masalah akan muncul ketika berinteraksi dengan fitur yang lebih baru di cabang pengembangan. Karena menerapkan perbaikan terbaru untuk perbaikan terbaru biasanya tidak diinginkan, ini menyebabkan pengembang menghabiskan waktu ekstra untuk mencoba memperbaiki perbaikan terbaru ke lingkungan pengembangan. Dalam banyak kasus, ini dapat menyebabkan utang teknis yang signifikan dan mengurangi stabilitas lingkungan pembangunan secara keseluruhan.
Ketika kegagalan terjadi di suatu lingkungan, semua perubahan diputar kembali sehingga lingkungan dikembalikan ke keadaan sebelumnya. Setiap perubahan pada basis kode harus memulai pipeline lagi dari tahap pertama. Ketika masalah muncul di lingkungan produksi, perbaikan harus melalui seluruh pipa juga. Waktu ekstra yang diperlukan untuk melewati lingkungan yang lebih rendah biasanya dapat diabaikan dibandingkan dengan masalah yang dihindari dengan menggunakan pendekatan ini. Karena seluruh tujuan lingkungan yang lebih rendah adalah untuk menangkap kesalahan sebelum mencapai produksi, melewati lingkungan ini melalui pendekatan Gitflow adalah risiko yang tidak efisien dan tidak perlu.
# Rilis manfaat dari pendekatan berbasis batang
Salah satu hal yang sering membuat perbaikan terbaru diperlukan adalah bahwa, dalam alur kerja lama, status aplikasi yang sedang dikerjakan pengembang mungkin berisi beberapa fitur yang belum dirilis yang belum aktif dalam produksi. Lingkungan produksi dan lingkungan pengembangan hanya menjadi sinkron ketika rilis terjadwal terjadi, dan kemudian mereka segera mulai menyimpang lagi hingga rilis terjadwal berikutnya.
Memiliki rilis terjadwal dimungkinkan dalam CI/CD proses penuh. Anda dapat menunda rilis kode ke produksi dengan menggunakan flag fitur. Namun, CI/CD proses yang sepenuhnya memungkinkan lebih banyak fleksibilitas dengan membuat rilis terjadwal tidak perlu. Bagaimanapun, *kontinu* adalah kata kunci dalam CI/CD, dan itu menunjukkan bahwa perubahan dilepaskan saat mereka siap. Hindari mempertahankan lingkungan rilis terpisah yang hampir selalu tidak sinkron dengan lingkungan pengujian yang lebih rendah.
Jika pipa tidak sepenuhnya CI/CD, divergensi antara lingkungan atas dan bawah biasanya terjadi pada tingkat cabang. Pengembang bekerja di cabang pengembangan dan memelihara cabang rilis terpisah yang diperbarui hanya ketika tiba waktunya untuk rilis terjadwal. Saat cabang pelepasan dan cabang pengembangan berbeda, komplikasi lain dapat muncul.
Selain lingkungan yang tidak sinkron, karena pengembang bekerja di cabang pengembangan dan menjadi terbiasa dengan status aplikasi yang jauh di depan apa yang ada dalam produksi, mereka harus menyesuaikan kembali dengan keadaan produksi setiap kali masalah muncul di sana. Keadaan cabang pengembangan bisa menjadi banyak fitur di depan produksi. Ketika pengembang bekerja di cabang itu setiap hari, sulit untuk mengingat apa yang dirilis dan tidak dirilis ke produksi. Ini menambah risiko bahwa bug baru akan diperkenalkan saat dalam proses memperbaiki bug lainnya. Hasil ini adalah siklus perbaikan yang tampaknya tak ada habisnya yang memperpanjang jadwal dan menunda rilis fitur selama berminggu-minggu, berbulan-bulan, atau bahkan bertahun-tahun.
# Manfaat keamanan dari pendekatan berbasis batang
CI/CD Proses penuh menyediakan satu sumber pendekatan kebenaran yang sepenuhnya otomatis untuk penyebaran. Pipa memiliki satu titik masuk. Pembaruan perangkat lunak memasuki pipeline di awal dan diteruskan apa adanya dari satu lingkungan ke lingkungan berikutnya. Jika masalah ditemukan pada tahap apa pun dalam pipeline, perubahan kode yang memperbaikinya harus melalui proses yang sama dan dimulai pada tahap pertama. Mengurangi titik masuk dalam pipa juga mengurangi kemungkinan cara kerentanan dapat dimasukkan ke dalam pipa.
Selain itu, karena titik masuk adalah titik terjauh dari lingkungan produksi, ini secara drastis mengurangi kemungkinan kerentanan mencapai produksi. Jika Anda menerapkan proses persetujuan manual dalam pipeline CI/CD sepenuhnya, Anda masih dapat mengizinkan pengambilan keputusan go atau no-go tentang apakah perubahan dipromosikan ke lingkungan berikutnya. Pengambil keputusan belum tentu orang yang sama yang menyebarkan perubahan. Ini memisahkan tanggung jawab untuk penyebaran perubahan kode dan pemberi persetujuan perubahan tersebut. Ini juga membuatnya lebih layak bagi pemimpin organisasi yang kurang teknis untuk melakukan peran pemberi persetujuan.
Terakhir, satu titik entri membantu Anda membatasi akses tulis ke konsol antarmuka pengguna (UI) lingkungan produksi untuk beberapa atau bahkan nol pengguna. Dengan mengurangi jumlah pengguna yang dapat membuat perubahan manual di konsol, Anda mengurangi risiko peristiwa keamanan. Kemampuan untuk mengelola konsol secara manual di lingkungan produksi jauh lebih diperlukan dalam alur kerja lama daripada dalam pendekatan CI/CD otomatis. Perubahan manual ini lebih sulit dilacak, ditinjau, dan diuji. Mereka biasanya dilakukan untuk menghemat waktu, tetapi dalam jangka panjang, mereka menambahkan utang teknis yang signifikan ke proyek.
Masalah keamanan konsol tidak selalu disebabkan oleh aktor jahat. Banyak masalah yang terjadi di konsol tidak disengaja. Paparan keamanan yang tidak disengaja sangat umum, dan telah menyebabkan munculnya model keamanan zero-trust. Model ini menyatakan, sebagian, bahwa kecelakaan keamanan lebih kecil kemungkinannya ketika bahkan staf internal memiliki akses sesedikit mungkin, juga dikenal sebagai izin *hak istimewa terkecil*. Melestarikan integritas lingkungan produksi dengan membatasi semua proses ke pipa otomatis secara praktis menghilangkan risiko masalah keamanan terkait konsol.