# Mengimplementasikan integrasi berkelanjutan dan pengiriman berkelanjutan
Bagian ini membahas cara-cara yang dapat Anda gunakan untuk mulai menerapkan model CI/CD di organisasi Anda. Laporan resmi ini tidak membahas tentang cara suatu organisasi dengan model transformasi cloud dan DevOps yang sudah matang membangun serta menggunakan alur CI/CD. Untuk membantu pengalaman DevOps Anda, AWS memiliki beberapa [Partner DevOps bersertifikat](https://aws.amazon.com/devops/partner-solutions/) yang menyediakan sumber daya dan alat. Untuk informasi lebih lanjut tentang mempersiapkan pindahan ke AWS Cloud, baca [Membangun Model Pengoperasian Cloud](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf).
# Jalur menuju integrasi berkelanjutan/pengiriman berkelanjutan
CI/CD dapat digambarkan sebagai alur (lihat gambar berikut), yang mana kode baru dikirimkan di satu ujung, diuji melalui serangkaian tahapan (sumber, pembuatan, penahapan, dan produksi), kemudian dipublikasikan sebagai kode yang siap untuk diproduksi. Jika organisasi Anda baru mengenal CI/CD, Anda dapat menerapkan pendekatan berulang pada alur ini. Artinya, Anda harus memulai dari hal kecil, dan mengulang setiap tahapan sehingga Anda dapat memahami dan mengembangkan kode Anda melalui cara yang dapat membantu pertumbuhan organisasi Anda.
![\[Alur CI/CD\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png)
*Alur CI/CD *
Setiap tahapan pada alur CI/CD dirancang sebagai unit logika dalam proses pengiriman. Selain itu, setiap tahapan berfungsi sebagai gerbang yang menyeleksi kode aspek tertentu. Saat kode diproses dalam sebuah alur, dapat diasumsikan bahwa kualitas kode tersebut akan lebih baik di tahap berikutnya karena semakin banyak aspek yang terus diverifikasi. Masalah-masalah yang tidak ditemukan di tahap awal menghentikan pemrosesan kode dalam alur. Hasil pengujian segera dikirim ke tim, dan semua pembangunan serta peluncuran dihentikan jika perangkat lunak gagal melewati tahapan ini.
Tahapan-tahapan ini hanya saran. Tahapan ini dapat disesuaikan dengan kebutuhan bisnis Anda. Beberapa tahap dapat diulang untuk beberapa jenis pengujian, keamanan, dan performa. Tergantung pada kompleksitas proyek dan struktur tim Anda, beberapa tahap dapat diulang beberapa kali pada tingkat yang berbeda. Misalnya, produk akhir dari satu tim bisa menjadi bagian dari proyek tim berikutnya. Artinya, produk akhir tim pertama kemudian dijadikan sebagai artefak dalam proyek tim berikutnya.
Adanya alur CI/CD akan berdampak besar pada pematangan kemampuan organisasi Anda. Organisasi harus mulai dengan langkah-langkah kecil dan tidak membangun alur yang sepenuhnya matang, dengan banyak lingkungan, banyak fase pengujian, dan otomatisasi pada semua tahap di awal. Perlu diingat bahwa bahkan organisasi dengan lingkungan CI/CD yang sangat matang masih harus terus meningkatkan alurnya.
Membangun organisasi dengan kemampuan CI/CD adalah sebuah perjalanan, dan ada banyak tujuan dalam prosesnya. Bagian selanjutnya membahas jalur yang mungkin diambil oleh organisasi Anda, dimulai dengan integrasi berkelanjutan pada tingkatan pengiriman berkelanjutan.
# Integrasi berkelanjutan
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png)
* Integrasi berkelanjutan—menyediakan sumber dan membangun *
Tahap pertama dalam perjalanan CI/CD adalah mengembangkan kematangan dalam integrasi berkelanjutan. Anda harus memastikan bahwa semua developer mengirim pembaruan kode ke repositori pusat (seperti yang di-host di CodeCommit atau GitHub) secara teratur dan menggabungkan semua perubahan ke cabang rilis untuk aplikasi. Developer dilarang mengisolasi kode. Jika diperlukan cabang fitur untuk jangka waktu tertentu, cabang fitur ini harus terus diperbarui dengan menggabungkan dari upstream sesering mungkin. Agar tim dapat mengembangkan disiplin dan didorong oleh proses, sebaiknya lakukan pengiriman pembaruan kode dengan unit pekerjaan lengkap sesering mungkin. Developer yang menggabungkan kode lebih awal dan sering, kemungkinan akan lebih sedikit menghadapi masalah integrasi ke depannya.
Anda juga harus mendorong developer untuk membuat unit pengujian sedini mungkin untuk aplikasi mereka dan menjalankan pengujian ini sebelum mendorong kode ke repositori pusat. Kesalahan yang ditemukan di awal proses pengembangan perangkat lunak adalah yang termurah dan paling mudah untuk diperbaiki.
Saat kode didorong ke cabang dalam repositori kode sumber, mesin alur kerja yang memantau cabang ini akan mengirim perintah ke alat pembangun untuk membangun kode dan menjalankan pengujian unit di lingkungan terkendali. Proses pembangunan harus disesuaikan ukurannya dengan tepat untuk menangani semua aktivitas, termasuk dorongan dan pengujian yang mungkin terjadi selama tahap pengiriman pembaruan, untuk mendapatkan umpan balik cepat. Pemeriksaan kualitas lainnya, seperti cakupan uji unit, pemeriksaan gaya, dan analisis statis, juga dapat terjadi di tahap ini. Terakhir, alat pembangun menciptakan satu atau beberapa build biner dan artefak lainnya, seperti gambar, stylesheet, dan dokumen untuk aplikasi.
# Pengiriman berkelanjutan: membuat lingkungan penahapan
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png)
* Pengiriman berkelanjutan—penahapan *
Pengiriman berkelanjutan (CD) adalah fase berikutnya dan memerlukan penerapan kode aplikasi di lingkungan penahapan, yang merupakan replika tumpukan produksi, dan menjalankan lebih banyak uji fungsional. Lingkungan penahapan bisa menjadi lingkungan statis yang sudah dibuat sebelumnya untuk pengujian, atau Anda dapat menyediakan dan mengonfigurasikan lingkungan dinamis dengan infrastruktur dan kode konfigurasi yang berkomitmen untuk menguji dan men-deploy kode aplikasi.
# Pengiriman berkelanjutan: membuat lingkungan produksi
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png)
* Pengiriman berkelanjutan—produksi *
Dalam urutan alur pengiriman/deployment, setelah lingkungan penahapan adalah lingkungan produksi, yang juga dibangun menggunakan infrastruktur sebagai kode (IaC).
# Deployment berkelanjutan
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png)
* Deployment berkelanjutan *
Tahap akhir dalam alur deployment CI/CD adalah deployment berkelanjutan, yang dapat mencakup otomatisasi penuh pada seluruh proses rilis perangkat lunak, termasuk deployment ke lingkungan produksi. Di lingkungan CI/CD yang sudah sepenuhnya matang, alur menuju lingkungan produksi sudah terotomatisasi penuh, memungkinkan keberhasilan deployment kode.
# Lebih dari sekadar kematangan
Meskipun sudah matang, organisasi akan terus mengembangkan model CI/CD untuk mencapai peningkatan berikut:
+ Lingkungan penahapan tambahan untuk pengujian performa, kepatuhan, keamanan, dan antarmuka pengguna (UI) tertentu
+ Uji unit infrastruktur dan kode konfigurasi bersama dengan kode aplikasi
+ Integrasi dengan sistem dan proses lain seperti tinjauan kode, pelacakan masalah, dan notifikasi peristiwa
+ Integrasi dengan migrasi skema basis data (jika ada)
+ Langkah tambahan untuk audit dan persetujuan bisnis
Bahkan organisasi yang paling matang dengan jaringan alur CI/CD multilingkungan yang kompleks pun terus berupaya mencapai peningkatan. DevOps adalah perjalanan, bukan tujuan. Umpan balik terkait alur terus dikumpulkan dan peningkatan kecepatan, skala, keamanan, serta keandalan dicapai sebagai kolaborasi antara berbagai bagian tim pengembangan.
# Tim
AWS merekomendasikan untuk membentuk tiga tim developer dalam mengimplementasikan lingkungan CI/CD: tim aplikasi, tim infrastruktur, dan tim alat (lihat gambar berikut). Organisasi ini mewakili serangkaian praktik terbaik yang telah dikembangkan dan diterapkan di perusahaan rintisan yang berkembang pesat, organisasi korporasi besar, dan di Amazon sendiri. Tim harus mengikuti konsep dua pizza, yaitu beranggotakan sekitar 10-12 orang. Hal ini mengikuti aturan komunikasi bahwa percakapan yang efisien akan mencapai batas seiring meningkatnya ukuran grup dan bertambahnya jalur komunikasi.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png)
* Tim aplikasi, infrastruktur, dan alat *
## Tim aplikasi
Tim aplikasi membuat aplikasi. Developer aplikasi memiliki backlog, riwayat, dan pengujian unit, serta mengembangkan fitur berdasarkan target aplikasi tertentu. Tujuan tim ini secara organisasi adalah untuk meminimalkan waktu yang diperlukan oleh para developer untuk selain tugas-tugas aplikasi inti.
Selain memiliki keterampilan pemrograman fungsional dalam bahasa aplikasi, tim aplikasi harus memiliki keterampilan platform dan pemahaman tentang konfigurasi sistem. Keterampilan ini akan membantu mereka untuk fokus hanya pada pengembangan fitur dan perlindungan aplikasi.
## Tim infrastruktur
Tim infrastruktur menulis kode yang mampu membuat sekaligus mengonfigurasi infrastruktur yang diperlukan untuk menjalankan aplikasi. Tim ini dapat menggunakan alat AWS, seperti AWS CloudFormation, atau alat generik, seperti Chef, Puppet, atau Ansible. Tim infrastruktur bertanggung jawab menentukan sumber daya apa yang dibutuhkan, dan bekerja sama dengan tim aplikasi. Tim infrastruktur mungkin hanya terdiri dari satu atau dua orang untuk aplikasi kecil.
Tim harus memiliki keterampilan dalam metode penyediaan infrastruktur, seperti AWS CloudFormation atau HashiCorp Terraform. Tim juga harus mengembangkan keterampilan otomatisasi konfigurasi dengan berbagai alat seperti Chef, Ansible, Puppet, atau Salt.
## Tim alat
Tim alat membangun dan mengelola alur CI/CD. Mereka bertanggung jawab atas infrastruktur dan alat penyusun alur. Tim ini bukan bagian dari tim dua pizza; tetapi mereka membuat alat yang digunakan oleh tim aplikasi dan infrastruktur di organisasi. Organisasi harus terus mematangkan tim alatnya, sehingga tim alat bisa selangkah lebih maju dari tim aplikasi dan infrastruktur yang juga semakin matang.
Tim alat harus terampil dalam membangun dan mengintegrasikan semua bagian alur CI/CD. Bagian ini meliputi pembangunan repositori kontrol sumber, mesin alur kerja, lingkungan build, pengujian kerangka kerja, dan repositori artefak. Tim ini dapat mengimplementasikan perangkat lunak seperti AWS CodeStar, AWS CodePipeline, AWS CodeCommit, AWS CodeDeploy, AWS CodeBuild, dan AWS CodeArtifact, serta Jenkins, GitHub, Artifactory, TeamCity, dan alat serupa lainnya. Beberapa organisasi menyebutnya tim DevOps, tetapi AWS menekankan bahwa DevOps adalah gabungan antara orang, proses, dan alat dalam pengiriman perangkat lunak.
# Tahap pengujian dalam integrasi berkelanjutan dan pengiriman berkelanjutan
Ketiga tim CI/CD harus menggabungkan pengujian ke dalam siklus hidup pengembangan perangkat lunak di berbagai tahap alur CI/CD. Secara keseluruhan, pengujian harus dimulai sedini mungkin. Piramida pengujian berikut merupakan konsep yang disampaikan oleh Mike Cohn dalam *Succeeding with Agile*. Piramida ini menunjukkan berbagai pengujian perangkat lunak berdasarkan biaya dan kecepatannya.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png)
* Piramida pengujian CI/CD *
Pengujian unit berada di bagian bawah piramida. Pengujian tersebut merupakan yang paling cepat dijalankan dan yang paling murah. Oleh karena itu, pengujian unit harus menjadi bagian terbesar dari strategi pengujian Anda. Baiknya adalah sekitar 70 persen. Pengujian unit harus memiliki cakupan kode yang hampir lengkap karena bug yang teridentifikasi fase ini dapat diperbaiki dengan cepat dan murah.
Pengujian layanan, komponen, dan integrasi dalam piramida berada di atas pengujian unit. Pengujian ini memerlukan lingkungan yang terperinci, sehingga keperluan infrastrukturnya lebih mahal dan lebih lambat untuk dijalankan. Pengujian performa dan kepatuhan berada pada tingkat di atasnya. Pengujian ini memerlukan lingkungan berkualitas produksi dan lebih mahal lagi. Pengujian UI dan penerimaan pengguna berada di bagian puncak piramida dan juga memerlukan lingkungan berkualitas produksi.
Semua pengujian ini adalah bagian dari strategi lengkap untuk menjamin kualitas perangkat lunak. Namun, demi kecepatan pengembangan, fokusnya adalah pada jumlah pengujian dan cakupan di separuh bagian bahwa piramida.
Bagian berikut membahas tahapan CI/CD.
## Menyiapkan sumber
Di awal proyek, penting untuk menyiapkan sumber untuk tempat menyimpan kode mentah serta perubahan konfigurasi dan skema. Di tahap sumber, pilih repositori kode sumber seperti yang di-host di GitHub atau AWS CodeCommit.
## Menyiapkan dan menjalankan pembangunan
Otomatisasi pembangunan sangat penting untuk proses CI. Saat menyiapkan otomatisasi pembangunan, tugas pertama adalah memilih alat pembangunan yang tepat. Ada banyak alat pembangunan, di antaranya:
+ Ant, Maven, dan Gradle untuk Java
+ Make untuk C/C\$1\$1
+ Grunt untuk JavaScript
+ Rake untuk Ruby
Alat pembangunan terbaik akan bergantung pada bahasa pemrograman proyek dan set keterampilan tim Anda. Setelah memilih alat pembangunan, semua dependensi harus ditentukan dengan jelas dalam skrip pembangunan, bersama dengan langkah pembangunan. Cara ini juga merupakan praktik terbaik untuk membuat versi artefak pembangunan akhir, sehingga lebih mudah di-deploy dan mengetahui masalah yang ada.
## Membangun
Di tahap pembangunan, alat pembangunan akan menjadikan setiap perubahan ke repositori kode sumber sebagai input, membangun perangkat lunak, dan menjalankan jenis pengujian berikut:
**Pengujian Unit –** Menguji bagian kode tertentu untuk memastikan kode berfungsi sebagaimana mestinya. Pengujian unit dilakukan oleh developer perangkat lunak selama tahap pengembangan. Di tahap ini, analisis kode statis, analisis aliran data, cakupan kode, dan proses verifikasi perangkat lunak lainnya dapat diterapkan.
**Analisis Kode Statis –** Pengujian ini dilakukan tanpa benar-benar mengeksekusi aplikasi setelah pembangunan dan pengujian unit. Analisis ini dapat membantu menemukan kesalahan pengodean dan celah keamanan, serta mampu memastikan kesesuaian dengan pedoman pengodean.
## Penahapan
Di fase penahapan, lingkungan penuh dibuat dan mirip dengan lingkungan produksi sebenarnya. Pengujian yang dilakukan:
**Pengujian integrasi** – Memverifikasi antarmuka antarkomponen terhadap desain perangkat lunak. Pengujian integrasi merupakan proses berulang serta memfasilitasi pembangunan antarmuka dan integritas sistem yang tangguh.
**Pengujian komponen** – Menguji pesan yang muncul di antara berbagai komponen dan hasilnya. Tujuan utama dari pengujian ini adalah idempotensi dalam pengujian komponen. Pengujian bisa mencakup data dalam volume yang sangat besar, atau situasi edge dan input abnormal.
**Pengujian sistem** – Menguji sistem end-to-end dan memverifikasi apakah perangkat lunak memenuhi persyaratan bisnis. Pengujian ini bisa mencakup pengujian antarmuka pengguna (UI), API, logika backend, dan status akhir.
**Pengujian performa –** Menentukan kemampuan respons dan stabilitas sistem saat dijalankan pada beban kerja tertentu. Pengujian performa juga digunakan untuk menyelidiki, mengukur, memvalidasi, atau memverifikasi atribut kualitas sistem lainnya, seperti skalabilitas, keandalan, dan penggunaan sumber daya. Jenis pengujian performa bisa mencakup uji beban, uji tekanan, dan uji lonjakan. Pengujian performa digunakan untuk pembandingan terhadap kriteria yang telah ditetapkan.
**Pengujian kepatuhan –** Memeriksa apakah perubahan kode sesuai dengan persyaratan spesifikasi dan/atau peraturan nonfungsional. Pengujian ini menentukan apakah Anda mengimplementasikan dan memenuhi standar yang ditetapkan.
**Pengujian penerimaan pengguna –** Memvalidasi alur bisnis end-to-end. Pengujian ini dilakukan oleh pengguna akhir dalam lingkungan penahapan dan mengonfirmasi apakah sistem sudah memenuhi spesifikasi persyaratan. Biasanya, di tahap ini pelanggan menerapkan metode pengujian alfa dan beta.
## Produksi
Setelah melewati pengujian sebelumnya, fase penahapan diulang di lingkungan produksi. Di fase ini, *Pengujian canary* akhir dapat diselesaikan dengan men-deploy kode baru pada sebuah subset server kecil atau bahkan satu server, atau satu Wilayah AWS sebelum men-deploy kode ke seluruh lingkungan produksi. Informasi terkait cara men-deploy ke produksi dengan aman tercantum di bagian [Metode deployment](deployment-methods.md).
Bagian berikutnya membahas pembangunan alur untuk menggabungkan tahapan dan pengujian ini.
## Membangun alur
Bagian ini membahas pembangunan alur. Mulai dengan membuat alur hanya dengan komponen yang diperlukan untuk CI, kemudian nantinya bertransisi ke alur pengiriman berkelanjutan dengan lebih banyak komponen dan tahapan. Bagian ini juga membahas bagaimana Anda dapat menggunakan persetujuan manual dan fungsi AWS Lambda untuk proyek besar, merencanakan banyak tim, cabang, dan Wilayah AWS.
# Memulai alur layak minimum untuk integrasi berkelanjutan
Perjalanan organisasi Anda menuju pengiriman berkelanjutan dimulai dengan alur layak minimum (MVP). Seperti yang dibahas dalam [Mengimplementasikan integrasi berkelanjutan dan pengiriman berkelanjutan](implementing-continuous-integration-and-continuous-delivery.md), tim dapat memulai dengan proses yang sangat sederhana, seperti mengimplementasikan alur yang dapat melakukan pemeriksaan gaya kode atau pengujian unit tunggal tanpa deployment.
Komponen kuncinya adalah alat orkestrasi pengiriman berkelanjutan. Untuk membantu Anda dalam membangun alur ini, Amazon mengembangkan [AWS CodeStar](https://aws.amazon.com/codestar).
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png)
* Halaman penyiapan AWS CodeStar *
AWS CodeStar menggunakan AWS CodePipeline, AWS CodeBuild, AWS CodeCommit, dan AWS CodeDeploy dengan proses, alat, templat, dan dasbor penyiapan terintegrasi. AWS CodeStar menyediakan segala yang Anda butuhkan untuk mengembangkan, membangun, dan men-deploy aplikasi di AWS. Hal ini memungkinkan Anda untuk mulai merilis kode lebih cepat. Pelanggan yang sudah terbiasa dengan Konsol Manajemen AWS dan menginginkan tingkat kontrol yang lebih tinggi dapat mengonfigurasikan pilihan alat developer secara manual serta menyediakan layanan AWS individual sesuai kebutuhan.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png)
* Dasbor AWS CodeStar *
AWS CodePipeline adalah layanan CI/CD yang dapat digunakan melalui AWS CodeStar atau Konsol Manajemen AWS untuk menghasilkan pembaruan infrastruktur serta aplikasi yang cepat dan andal. AWS CodePipeline membangun, menguji, dan men-deploy kode jika ada perubahan kode, berdasarkan model proses rilis yang Anda tentukan. Hal ini memungkinkan Anda untuk mengirim fitur serta pembaruan dengan cepat dan andal. Anda dapat membangun solusi end-to-end dengan mudah menggunakan plugin kami yang sudah dibuat sebelumnya untuk layanan pihak ketiga yang populer seperti GitHub atau mengintegrasikan plugin kustom Anda sendiri ke tahap proses rilis Anda. Dengan AWS CodePipeline, Anda hanya perlu membayar sesuai penggunaan. Tidak ada biaya awal atau komitmen jangka panjang.
Langkah AWS CodeStar dan AWS CodePipeline memetakan langsung ke [tahap CI/CD penyediaan sumber, pembangunan, penahapan, dan produksi](testing-stages-in-continuous-integration-and-continuous-delivery.md). Tidak perlu langsung memulai dengan pengiriman berkelanjutan. Anda dapat memulai dengan alur dua langkah sederhana yang memeriksa repositori sumber dan melakukan tindakan pembangunan:
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png)
* AWS CodePipeline — tahap penyediaan sumber dan pembangunan *
Untuk AWS CodePipeline, tahap penyediaan sumber dapat menerima input dari GitHub, AWS CodeCommit, dan Amazon Simple Storage Service (Amazon S3). Otomatisasi proses pembuatan adalah langkah pertama yang penting untuk mengimplementasikan pengiriman berkelanjutan dan deployment berkelanjutan. Tidak adanya keterlibatan manusia dalam memproduksi artefak pembangunan menghilangkan beban tim Anda, meminimalkan kesalahan yang disebabkan oleh pengemasan manual, dan Anda dapat mulai lebih sering mengemas artefak habis pakai.
AWS CodePipeline berfungsi baik dengan AWS CodeBuild, layanan pembangunan terkelola penuh, untuk mempermudah penyiapan langkah pembangunan alur serta mampu mengemas kode dan menjalankan pengujian unit. Dengan AWS CodeBuild, Anda tidak perlu menyediakan, mengelola, atau menskalakan server pembuatan Anda sendiri. AWS CodeBuild menskalakan terus-menerus dan memproses beberapa build secara bersamaan sehingga build Anda tidak perlu menunggu dalam antrean. AWS CodePipeline juga terintegrasi dengan server pembuatan seperti Jenkins, Solano CI, dan TeamCity.
Misalnya, dalam tahap pembangunan berikut, tiga tindakan (pengujian unit, pemeriksaan gaya kode, dan pengumpulan metrik kode) berjalan secara paralel. Dengan AWS CodeBuild, langkah-langkah ini dapat ditambahkan sebagai proyek baru tanpa upaya lebih dalam membangun atau menginstal server pembuatan untuk menangani beban.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png)
* AWS CodePipeline — fungsionalitas build *
Tahap penyediaan sumber dan pembangunan yang ditampilkan pada gambar *AWS CodePipeline — tahap sumber dan pembangunan *, bersama dengan proses dan otomatisasi pendukung, mendukung perubahan tim Anda menuju Integrasi Berkelanjutan. Di tingkat kematangan ini, developer harus rutin memperhatikan hasil pengujian dan pembangunan. Mereka juga perlu meningkatkan dan memelihara kondisi dasar pengujian unit. Hal ini dapat memperkuat kepercayaan diri seluruh tim dalam alur CI/CD dan penggunaan lainnya.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png)
*Tahapan AWS CodePipeline*
# Alur pengiriman berkelanjutan
Setelah implementasi alur integrasi berkelanjutan dan penetapan proses pendukung, tim Anda dapat mulai bertransisi dalam alur pengiriman berkelanjutan. Dalam transisi ini, tim harus mengotomatiskan deployment dan pembangunan aplikasi.
Alur pengiriman berkelanjutan ditandai dengan adanya tahapan dan langkah produksi, yang mana langkah produksi dilakukan setelah adanya persetujuan manual.
Sama seperti pembangunan alur integrasi berkelanjutan, tim Anda bisa mulai membangun alur pengiriman berkelanjutan secara bertahap dengan menuliskan skrip deployment-nya.
Beberapa langkah deployment dapat diabstraksikan dengan layanan AWS yang ada, tergantung pada kebutuhan aplikasi. Misalnya, AWS CodePipeline berintegrasi langsung dengan AWS CodeDeploy, layanan yang mengotomatiskan deployment kode ke instans Amazon EC2 dan instans yang dijalankan secara on-premise, AWS OpsWorks, layanan pengelolaan konfigurasi yang membantu pengoperasian aplikasi menggunakan Chef, dan ke AWS Elastic Beanstalk, layanan untuk men-deploy dan menskalakan layanan dan aplikasi web.
AWS memiliki [dokumentasi](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment) lengkap tentang cara mengimplementasikan dan mengintegrasikan AWS CodeDeploy dengan alur dan infrastruktur Anda.
Setelah tim Anda berhasil mengotomatiskan deployment aplikasi, tahapan deployment dapat diperluas dengan berbagai pengujian. Misalnya, Anda dapat menambahkan integrasi unik lainnya dengan layanan seperti Ghost Inspector, Runscope, dan lainnya seperti yang ditunjukkan pada gambar berikut.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png)
* AWS CodePipeline—pengujian kode dalam tahapan deployment *
# Menambahkan tindakan Lambda
AWS CodeStar dan AWS CodePipeline mendukung [integrasi dengan AWS Lambda](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html). Integrasi ini memungkinkan implementasi serangkaian tugas, seperti membuat sumber daya kustom di lingkungan Anda, mengintegrasikan dengan sistem pihak ketiga (seperti Slack), dan melakukan pemeriksaan pada lingkungan yang baru Anda deploy.
Fungsi Lambda dapat digunakan dalam alur CI/CD untuk melakukan tugas-tugas berikut:
+ Membuat perubahan ke lingkungan Anda dengan menerapkan atau memperbarui templat AWS CloudFormation.
+ Membuat sumber daya sesuai permintaan dalam satu tahap alur menggunakan AWS CloudFormation dan menghapusnya di tahap lain.
+ Men-deploy versi aplikasi dengan waktu henti nol AWS Elastic Beanstalk dengan fungsi Lambda yang menukar nilai [catatan Nama Kanonik](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) (CNAME).
+ Men-deploy ke instans Docker Amazon Elastic Container Service (ECS).
+ Mencadangkan sumber daya sebelum membangun atau men-deploy dengan membuat snapshot AMI.
+ Menambahkan integrasi dengan produk pihak ketiga ke alur Anda, seperti mem-posting pesan ke klien Internet Relay Chat (IRC).
# Persetujuan manual
Tambahkan tindakan persetujuan ke dalam sebuah tahap pada alur jika Anda ingin menghentikan pemrosesan alur sehingga seseorang dengan izin AWS Identity and Access Management (IAM) yang diperlukan dapat menyetujui atau menolak tindakan tersebut.
Jika tindakan disetujui, pemrosesan alur akan dilanjutkan. Jika tindakan ditolak—atau jika tidak ada orang yang menyetujui atau menolak tindakan ini dalam waktu tujuh hari sejak alur mencapai tindakan ini dan berhenti—tindakan dianggap gagal, dan pemrosesan alur tidak dilanjutkan.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png)
* AWS CodeDeploy—persetujuan manual *
# Men-deploy perubahan kode infrastruktur dalam alur CI/CD
AWS CodePipeline memungkinkan Anda untuk memilih AWS CloudFormation sebagai tindakan deployment dalam tahap alur mana pun. Anda kemudian dapat memilih tindakan spesifik yang ingin Anda AWS CloudFormation lakukan, seperti membuat atau menghapus tumpukan serta membuat atau mengeksekusi [set perubahan](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952). [Tumpukan](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929) merupakan suatu konsep AWS CloudFormation dan mewakili sekelompok sumber daya AWS terkait. Meskipun ada banyak cara penyediaan Infrastruktur sebagai code (IaC), AWS CloudFormation adalah alat komprehensif yang direkomendasikan oleh AWS sebagai solusi lengkap dan dapat diskalakan yang dapat menjelaskan rangkaian sumber daya AWS terlengkap sebagai kode. AWS merekomendasikan untuk menggunakan AWS CloudFormation dalam proyek AWS CodePipeline untuk [melacak pengujian dan perubahan infrastruktur](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html).
# CI/CD untuk aplikasi nirserver
Anda juga dapat menggunakan AWS CodeStar, AWS CodePipeline, AWS CodeBuild, dan AWS CloudFormation untuk membangun alur CI/CD untuk aplikasi nirserver. Aplikasi nirserver mengintegrasikan layanan terkelola seperti [Amazon Cognito](https://aws.amazon.com/cognito), Amazon S3, dan Amazon DynamoDB dengan layanan yang didorong peristiwa, serta AWS Lambda untuk men-deploy aplikasi tanpa perlu pengelolaan server. Jika Anda adalah developer aplikasi nirserver, Anda dapat menggunakan kombinasi antara AWS CodePipeline, AWS CodeBuild, dan AWS CloudFormation untuk mengotomatiskan pembangunan, pengujian, serta deployment aplikasi nirserver yang ditunjukkan dalam templat yang dibuat dengan AWS Serverless Application Model. Untuk informasi lebih lanjut, lihat dokumentasi AWS Lambda untuk [Mengotomatiskan Deployment Aplikasi Berbasis Lambda](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html).
Anda juga dapat membuat jaringan alur CI/CD yang aman sesuai praktik terbaik organisasi Anda dengan AWS Serverless Application Model Pipeline (AWS SAM Pipeline). AWS SAM Pipeline adalah fitur baru AWS SAM CLI yang membantu Anda mengakses manfaat CI/CD dalam hitungan menit, seperti mempercepat frekuensi deployment, mempersingkat waktu tunggu untuk perubahan, dan mengurangi kesalahan deployment. AWS SAM Pipeline dilengkapi serangkaian templat alur default untuk AWS CodeBuild/CodePipeline sesuai praktik terbaik deployment AWS. Untuk informasi lebih lanjut dan untuk melihat tutorial, lihat blog [ Memperkenalkan AWS SAM Pipeline](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/).
# Alur untuk beberapa tim, cabang, dan Wilayah AWS
Untuk proyek besar, tidak jarang beberapa tim proyek mengerjakan komponen yang berbeda. Jika beberapa tim menggunakan repositori kode tunggal, maka dapat dipetakan sehingga setiap tim memiliki cabangnya sendiri. Cabang integrasi atau rilis untuk penggabungan akhir proyek juga harus ada. Jika menggunakan arsitektur layanan mikro atau berorientasi pada layanan, setiap tim bisa memiliki repositori kode sendiri.
Dalam skenario pertama, jika menggunakan alur tunggal, satu tim dapat memengaruhi kemajuan tim lain dengan memblokir alur. AWS menyarankan agar Anda membuat alur khusus untuk cabang tim dan alur rilis lainnya untuk pengiriman produk akhir.
# Integrasi alur dengan AWS CodeBuild
AWS CodeBuild dirancang untuk membantu organisasi Anda membangun proses pembangunan dengan ketersediaan tinggi dan skala hampir tak terbatas. AWS CodeBuild menyediakan lingkungan pemula untuk beberapa bahasa populer dan kemampuan untuk menjalankan kontainer Docker yang Anda tentukan.
Dengan manfaat integrasi ketat bersama AWS CodeCommit, AWS CodePipeline, dan AWS CodeDeploy, serta tindakan Lambda CodePipeline dan Git, alat CodeBuild sangat fleksibel.
Perangkat lunak dapat dibangun dengan menyertakan file `buildspec.yml` yang mengidentifikasi setiap langkah pembangunan, termasuk tindakan sebelum dan sesudah pembangunan, atau tindakan tertentu melalui alat CodeBuild.
Anda dapat melihat detail riwayat masing-masing pembangunan menggunakan dasbor CodeBuild. Peristiwa disimpan sebagai berkas log Amazon CloudWatch Logs.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png)
* Berkas log CloudWatch Logs di AWS CodeBuild *
# Integrasi alur dengan Jenkins
Anda dapat menggunakan alat pembangunan Jenkins [untuk membuat alur pengiriman](https://www.jenkins.io/doc/book/pipeline/getting-started/). Alur ini menggunakan tugas standar yang menentukan langkah-langkah untuk mengimplementasikan tahapan pengiriman berkelanjutan. Namun, pendekatan ini mungkin tidak optimal untuk proyek yang lebih besar karena status alur saat ini tidak sama antara mulai ulang Jenkins, implementasi persetujuan manual tidak mudah, dan pelacakan status alur yang kompleks dapat menjadi rumit.
Sebagai gantinya, AWS sebaiknya implementasikan pengiriman berkelanjutan dengan Jenkins menggunakan [Plugin AWS Code Pipeline](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin). Plugin ini memungkinkan penjabaran alur kerja kompleks menggunakan bahasa khusus domain seperti Groovy, dan dapat digunakan untuk mengatur alur yang kompleks. Fungsionalitas plugin AWS Code Pipeline dapat ditingkatkan menggunakan plugin satelit, seperti [ Plugin Tampilan Tahapan Alur](https://plugins.jenkins.io/aws-codepipeline/), yang memvisualisasikan kemajuan tahapan terbaru yang ditentukan dalam alur, atau [ Plugin Multicabang Alur](https://plugins.jenkins.io/workflow-multibranch/), yang mengelompokkan build dari cabang yang berbeda.
AWS menyarankan untuk menyimpan konfigurasi alur dalam *Jenkinsfile* dan memeriksanya dalam repositori kode sumber. Hal ini memungkinkan pelacakan perubahan pada kode alur dan menjadi poin penting ketika bekerja dengan Plugin Multicabang Alur. AWS menyarankan untuk membagi alur menjadi beberapa tahap. Hal ini secara logis mengelompokkan langkah-langkah alur dan juga memungkinkan Plugin Tampilan Tahapan Alur untuk memvisualisasikan status terbaru alur.
Gambar berikut menunjukkan sampel alur Jenkins, dengan empat tahap yang sudah ditentukan dan divisualisasikan oleh Plugin Tampilan Tahapan Alur.
![\[alt text not found\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png)
*Tahapan alur Jenkins yang sudah ditentukan dan divisualisasikan oleh Plugin Tampilan Tahapan Alur*