Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memahami CI/CD
Integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) adalah proses mengotomatisasi siklus hidup rilis perangkat lunak. Dalam beberapa kasus, *D* in juga CI/CD dapat berarti *penyebaran*. Perbedaan antara *pengiriman berkelanjutan* dan *penerapan berkelanjutan* terjadi ketika Anda merilis perubahan pada lingkungan produksi. Dengan pengiriman berkelanjutan, persetujuan manual diperlukan sebelum mempromosikan perubahan produksi. Penerapan berkelanjutan menampilkan aliran tanpa gangguan melalui keseluruhan pipeline, dan tidak ada persetujuan eksplisit yang diperlukan. Karena strategi ini membahas CI/CD konsep umum, rekomendasi dan informasi yang diberikan berlaku untuk pengiriman berkelanjutan dan pendekatan penyebaran berkelanjutan.
CI/CD automates much or all of the manual processes traditionally required to get new code from a commit into production. A CI/CD pipeline encompasses the source, build, test, staging, and production stages. In each stage, the CI/CD pipelines provisions any infrastructure that is needed to deploy or test the code. By using a CI/CDpipeline, tim pengembangan dapat membuat perubahan pada kode yang kemudian diuji secara otomatis dan didorong ke penerapan.
Mari kita tinjau CI/CD proses dasar sebelum membahas beberapa cara yang dapat Anda, secara sadar atau tidak sadar, menyimpang dari tahap dan aktivitas penuh CI/CD. The following diagram shows the CI/CD di setiap tahap.
![\[Lima tahap CI/CD proses dan kegiatan dan lingkungan masing-masing.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## Tentang integrasi berkelanjutan
Integrasi berkelanjutan terjadi dalam repositori kode, seperti repositori Git di. GitHub Anda memperlakukan satu cabang utama sebagai sumber kebenaran untuk basis kode, dan Anda membuat cabang berumur pendek untuk pengembangan fitur. Anda mengintegrasikan cabang fitur ke cabang utama saat Anda siap untuk menerapkan fitur ke lingkungan atas. Cabang fitur tidak pernah digunakan langsung ke lingkungan atas. Untuk informasi selengkapnya, lihat [Pendekatan berbasis batang](fully-cicd-process-differences.md#trunk-based-approach) dalam panduan ini.
*Proses integrasi berkelanjutan*
1. Pengembang membuat cabang baru dari cabang utama.
1. Pengembang membuat perubahan dan membangun dan menguji secara lokal.
1. Ketika perubahan sudah siap, pengembang membuat [permintaan tarik](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (GitHub dokumentasi) dengan cabang utama sebagai tujuan.
1. Kode ditinjau.
1. Ketika kode disetujui, itu digabungkan ke cabang utama.
## Tentang pengiriman berkelanjutan
Pengiriman berkelanjutan terjadi di lingkungan yang terisolasi, seperti lingkungan pengembangan dan lingkungan produksi. Tindakan yang terjadi di setiap lingkungan dapat bervariasi. Seringkali, salah satu tahap pertama digunakan untuk membuat pembaruan pada pipa itu sendiri sebelum melanjutkan. Hasil akhir dari penerapan adalah bahwa setiap lingkungan diperbarui dengan perubahan terbaru. Jumlah lingkungan pengembangan untuk bangunan dan pengujian juga bervariasi, tetapi kami sarankan Anda menggunakan setidaknya dua. Dalam pipa, setiap lingkungan diperbarui dalam urutan signifikansinya, berakhir dengan lingkungan yang paling penting, lingkungan produksi.
*Proses pengiriman berkelanjutan*
Bagian pengiriman berkelanjutan dari pipeline dimulai dengan menarik kode dari cabang utama repositori sumber dan meneruskannya ke tahap pembuatan. Dokumen infrastruktur sebagai kode (IAc) untuk repositori menguraikan tugas-tugas yang dilakukan di setiap tahap. Meskipun menggunakan dokumen IAc tidak wajib, layanan atau alat IAC, seperti [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)atau [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html), sangat disarankan. Langkah-langkah yang paling umum meliputi:
1. Tes unit
1. Membangun kode
1. Penyediaan sumber daya
1. Tes integrasi
Jika terjadi kesalahan atau pengujian apa pun gagal pada tahap apa pun dalam pipa, tahap saat ini kembali ke keadaan sebelumnya, dan pipa dihentikan. Perubahan selanjutnya harus dimulai di repositori kode dan melalui proses penuh CI/CD .
# Tes untuk CI/CD jaringan pipa
Dua jenis pengujian otomatis yang biasa disebut dalam pipeline penyebaran adalah *pengujian unit dan tes* *integrasi*. Namun, ada banyak jenis pengujian yang dapat Anda jalankan pada basis kode dan lingkungan pengembangan. [Arsitektur Referensi Pipeline AWS Deployment](https://pipelines.devops.aws.dev/application-pipeline/) mendefinisikan jenis pengujian berikut:
+ **Unit test** — Tes ini membangun dan menjalankan kode aplikasi untuk memverifikasi bahwa itu bekerja sesuai dengan harapan. Mereka mensimulasikan semua dependensi eksternal yang digunakan dalam basis kode. Contoh alat uji unit termasuk [JUnit](https://junit.org/), [Jest](https://jestjs.io/), dan [pytest](https://pytest.org/).
+ **Tes integrasi** — Pengujian ini memverifikasi bahwa aplikasi memenuhi persyaratan teknis dengan menguji lingkungan pengujian yang disediakan. Contoh alat uji integrasi termasuk [Mentimun](https://cucumber.io/), [VRest NG](https://vrest.io/), dan [tes integ](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) (untuk). AWS CDK
+ **Tes penerimaan** - Pengujian ini memverifikasi bahwa aplikasi memenuhi persyaratan pengguna dengan menguji lingkungan pengujian yang disediakan. Contoh alat uji penerimaan termasuk [Cypress](https://cypress.io/) dan [Selenium](https://selenium.dev/).
+ **Tes sintetis** — Tes ini berjalan terus menerus di latar belakang untuk menghasilkan lalu lintas dan memverifikasi bahwa sistemnya sehat. Contoh alat uji sintetis termasuk [Amazon CloudWatch Synthetics dan [Dynatrace](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/) Synthetic](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) Monitoring.
+ **Uji kinerja - Tes** ini mensimulasikan kapasitas produksi. Mereka menentukan apakah aplikasi memenuhi persyaratan kinerja dan membandingkan metrik dengan kinerja masa lalu. [Contoh alat uji kinerja termasuk [Apache JMeter](https://jmeter.apache.org/), [Locust](https://locust.io/), dan Gatling.](https://gatling.io/)
+ **Tes ketahanan** — Juga dikenal sebagai *pengujian kekacauan*, tes ini menyuntikkan kegagalan ke lingkungan untuk mengidentifikasi area risiko. Periode ketika kegagalan disuntikkan kemudian dibandingkan dengan periode tanpa kegagalan. [Contoh alat uji ketahanan termasuk [AWS Fault Injection Service](https://aws.amazon.com/fis/)dan Gremlin.](https://www.gremlin.com/)
+ **Tes keamanan aplikasi statis (SAST)** — Tes ini menganalisis kode untuk pelanggaran keamanan, seperti [injeksi SQL](https://owasp.org/www-community/attacks/SQL_Injection) atau [cross-site scripting](https://owasp.org/www-community/attacks/xss/) (XSS). Contoh alat SAST termasuk [Amazon CodeGuru](https://aws.amazon.com/codeguru/), [SonarQube](https://www.sonarqube.org/), dan [Checkmarx](https://checkmarx.com/).
+ **Dynamic Application Security Test (DAST)** — Tes ini juga dikenal sebagai *pengujian penetrasi* atau *pengujian pena*. Mereka mengidentifikasi kerentanan, seperti injeksi SQL atau XSS di lingkungan pengujian yang disediakan. [Contoh alat DAST termasuk [Zed Attack Proxy (ZAP)](https://www.zaproxy.org/) dan HCL. AppScan](https://www.hcltechsw.com/appscan) Untuk informasi selengkapnya, lihat [Pengujian Penetrasi](https://aws.amazon.com/security/penetration-testing/).
Tidak semua CI/CD jaringan pipa sepenuhnya menjalankan semua tes ini. Namun, minimal, pipeline harus menjalankan pengujian unit dan pengujian SAST pada basis kode serta tes integrasi dan penerimaan pada lingkungan pengujian.
# Metrik untuk jaringan pipa CI/CD
Menurut [Arsitektur Referensi Pipeline AWS Deployment](https://pipelines.devops.aws.dev/application-pipeline/), Anda harus, setidaknya, melacak empat metrik berikut untuk CI/CD pipeline:
+ **Lead time** — Jumlah rata-rata waktu yang dibutuhkan untuk satu komitmen untuk masuk ke dalam produksi. Kami merekomendasikan untuk menargetkan lead time antara 1 jam dan 1 hari, yang sesuai untuk kasus penggunaan Anda.
+ **Frekuensi penyebaran** — Jumlah penyebaran produksi dalam periode waktu tertentu. Kami merekomendasikan penargetan frekuensi penerapan antara beberapa kali setiap hari hingga dua kali setiap minggu, yang sesuai untuk kasus penggunaan Anda.
+ **Mean time between failure (MTBF)** — Rata-rata jumlah waktu antara awal pipa yang berhasil dan dimulainya pipa yang gagal. Kami merekomendasikan untuk menargetkan MTBF setinggi mungkin. Untuk informasi selengkapnya, lihat [Meningkatkan MTBF](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html).
+ **Mean time to recovery (MTTR)** — Jumlah rata-rata waktu antara awal pipa yang gagal dan dimulainya pipa sukses berikutnya. Kami merekomendasikan penargetan MTTR yang serendah mungkin. Untuk informasi selengkapnya, lihat [Mengurangi MTTR](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html).
Metrik ini membantu tim melacak kemajuan mereka untuk menjadi CI/CD sepenuhnya. Tim harus melakukan diskusi terbuka dengan pemangku kepentingan organisasi mengenai apa tujuan optimal yang seharusnya. Situasi dan kebutuhan sangat bervariasi dari organisasi ke organisasi, dan bahkan dari tim ke tim.
Sangat penting untuk diingat bahwa perubahan yang cepat dan drastis biasanya meningkatkan risiko masalah yang timbul. Tetapkan tujuan untuk mencapai peningkatan kecil dan bertahap. Waktu tunggu optimal yang umum untuk CI/CD jaringan pipa sepenuhnya kurang dari 3 jam. Sebuah tim yang memulai dengan lead time 5,2 hari harus menargetkan pengurangan satu hari setiap beberapa minggu. Setelah tim ini mencapai lead time satu hari atau kurang, mereka dapat tinggal di sana selama beberapa bulan dan pindah ke lead time yang lebih agresif hanya jika tim dan pemangku kepentingan organisasi menganggapnya perlu.