

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Memahami DevOps lingkungan
<a name="understanding-the-devops-environments"></a>

Untuk memahami strategi percabangan, Anda harus memahami tujuan dan kegiatan yang terjadi di setiap lingkungan. Membangun beberapa lingkungan membantu Anda memisahkan aktivitas pengembangan menjadi beberapa tahap, memantau aktivitas tersebut, dan mencegah pelepasan fitur yang tidak disetujui secara tidak disengaja. Anda dapat memiliki satu atau lebih Akun AWS di setiap lingkungan. 

Sebagian besar organisasi memiliki beberapa lingkungan yang diuraikan untuk digunakan. Namun, jumlah lingkungan dapat bervariasi menurut organisasi dan sesuai dengan kebijakan pengembangan perangkat lunak. Seri dokumentasi ini mengasumsikan bahwa Anda memiliki lima lingkungan umum berikut yang menjangkau pipeline pengembangan Anda, meskipun mereka mungkin dipanggil dengan nama yang berbeda:
+ **Sandbox** — Lingkungan di mana pengembang menulis kode, membuat kesalahan, dan melakukan bukti kerja konsep.
+ **Pengembangan** — Lingkungan di mana pengembang mengintegrasikan kode mereka untuk mengonfirmasi bahwa semuanya berfungsi sebagai aplikasi tunggal yang kohesif.
+ **Pengujian** — Lingkungan di mana tim QA atau pengujian penerimaan berlangsung. Tim sering melakukan pengujian kinerja atau integrasi di lingkungan ini.
+ **Staging** — Lingkungan praproduksi tempat Anda memvalidasi bahwa kode dan infrastruktur berfungsi seperti yang diharapkan dalam keadaan setara produksi. Lingkungan ini dikonfigurasi agar semirip mungkin dengan lingkungan produksi.
+ **Produksi** — Lingkungan yang menangani lalu lintas dari pengguna akhir dan pelanggan Anda.

Bagian ini menjelaskan setiap lingkungan secara rinci. Ini juga menjelaskan langkah-langkah build, langkah penerapan, dan kriteria keluar untuk setiap lingkungan sehingga Anda dapat melanjutkan ke yang berikutnya. Gambar berikut menunjukkan lingkungan ini secara berurutan.

![\[DevOps Lingkungan umum dalam urutan berurutan\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/choosing-git-branch-approach/images/devops-environments.png)


**Topics**
+ [

# Lingkungan kotak pasir
](sandbox-environment.md)
+ [

# Lingkungan pengembangan
](development-environment.md)
+ [

# Lingkungan pengujian
](testing-environment.md)
+ [

# Lingkungan pementasan
](staging-environment.md)
+ [

# Lingkungan produksi
](production-environment.md)

# Lingkungan kotak pasir
<a name="sandbox-environment"></a>

*Lingkungan kotak pasir* adalah tempat pengembang menulis kode, membuat kesalahan, dan melakukan bukti kerja konsep. Anda dapat menerapkan ke lingkungan sandbox dari workstation lokal atau melalui skrip di workstation lokal.

## Akses
<a name="access"></a>

Pengembang harus memiliki akses penuh ke lingkungan kotak pasir.

## Membangun langkah
<a name="build-steps"></a>

Pengembang menjalankan build secara manual di workstation lokal mereka saat mereka siap menerapkan perubahan ke lingkungan kotak pasir.

1. Gunakan [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) untuk memindai informasi sensitif

1. Lint kode sumber

1. Membangun dan mengkompilasi kode sumber, jika berlaku

1. Lakukan pengujian unit

1. Lakukan analisis cakupan kode

1. Lakukan analisis kode statis

1. Membangun infrastruktur sebagai kode (IAc)

1. Lakukan analisis keamanan IAc

1. Ekstrak lisensi open source

1. Publikasikan artefak build

## Langkah-langkah penyebaran
<a name="deployment-steps"></a>

Jika Anda menggunakan model Gitflow atau Trunk, langkah penerapan secara otomatis dimulai ketika `feature` cabang berhasil dibangun di lingkungan kotak pasir. Jika Anda menggunakan model GitHub Flow, Anda akan melakukan langkah penerapan berikut secara manual. Berikut ini adalah langkah-langkah penerapan di lingkungan sandbox:

1. Unduh artefak yang diterbitkan

1. Lakukan pembuatan versi database

1. Lakukan penyebaran IAc

1. Lakukan pengujian integrasi

## Harapan sebelum pindah ke lingkungan pembangunan
<a name="expectations-before-moving-to-the-development-environment"></a>
+ Sukses membangun `feature` cabang di lingkungan kotak pasir
+ Pengembang telah menerapkan dan menguji fitur secara manual di lingkungan kotak pasir

# Lingkungan pengembangan
<a name="development-environment"></a>

*Lingkungan pengembangan* adalah tempat pengembang mengintegrasikan kode mereka bersama-sama untuk memastikan semuanya berfungsi sebagai satu aplikasi yang kohesif. Di Gitflow, lingkungan pengembangan berisi fitur terbaru yang disertakan oleh permintaan gabungan dan siap untuk dirilis. Dalam strategi GitHub Flow and Trunk, lingkungan pengembangan dianggap sebagai lingkungan pengujian, dan basis kode mungkin tidak stabil dan tidak cocok untuk diterapkan ke produksi.

## Akses
<a name="access"></a>

Tetapkan izin sesuai dengan prinsip hak istimewa paling sedikit. *Keistimewaan paling sedikit* adalah praktik keamanan terbaik untuk memberikan izin minimum yang diperlukan untuk melakukan tugas. Pengembang harus memiliki lebih sedikit akses ke lingkungan pengembangan daripada yang mereka miliki ke lingkungan kotak pasir.

## Membangun langkah
<a name="build-steps"></a>

Membuat permintaan gabungan ke `develop` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) secara otomatis memulai build.

1. Gunakan [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) untuk memindai informasi sensitif

1. Lint kode sumber

1. Membangun dan mengkompilasi kode sumber, jika berlaku

1. Lakukan pengujian unit

1. Lakukan analisis cakupan kode

1. Lakukan analisis kode statis

1. Membangun IAc

1. Lakukan analisis keamanan IAc

1. Ekstrak lisensi open source

## Langkah-langkah penyebaran
<a name="deployment-steps"></a>

Jika Anda menggunakan model Gitflow, langkah penerapan secara otomatis dimulai ketika `develop` cabang berhasil dibangun di lingkungan pengembangan. Jika Anda menggunakan model GitHub Flow atau model Trunk, maka langkah penerapan akan dimulai secara otomatis saat permintaan gabungan dibuat terhadap cabang. `main` Berikut ini adalah langkah-langkah penerapan di lingkungan pengembangan:

1. Unduh artefak yang diterbitkan dari langkah-langkah pembuatan

1. Lakukan pembuatan versi database

1. Lakukan penyebaran IAc

1. Lakukan tes integrasi

## Harapan sebelum pindah ke lingkungan pengujian
<a name="expectations-before-moving-to-the-testing-environment"></a>
+ Pembuatan dan penerapan `develop` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) yang berhasil di lingkungan pengembangan
+ Pengujian unit lolos pada 100%
+ Membangun IAc yang sukses
+ Artefak penyebaran berhasil dibuat
+ Pengembang telah melakukan verifikasi manual untuk mengonfirmasi bahwa fitur tersebut berfungsi seperti yang diharapkan

# Lingkungan pengujian
<a name="testing-environment"></a>

Personel jaminan kualitas (QA) menggunakan lingkungan pengujian untuk memvalidasi fitur. Mereka menyetujui perubahan setelah mereka menyelesaikan pengujian. Ketika mereka menyetujui, cabang pindah ke lingkungan berikutnya, pementasan. Di Gitflow, lingkungan ini dan lainnya di atasnya hanya tersedia untuk penerapan dari `release` cabang. `release`Cabang didasarkan pada `develop` cabang yang berisi fitur yang direncanakan.

## Akses
<a name="access"></a>

Tetapkan izin sesuai dengan prinsip hak istimewa paling sedikit. Pengembang harus memiliki lebih sedikit akses ke lingkungan pengujian daripada yang mereka miliki ke lingkungan pengembangan. Personel QA memerlukan izin yang cukup untuk menguji fitur.

## Membangun langkah
<a name="build-steps"></a>

Proses pembuatan di lingkungan ini hanya berlaku untuk perbaikan bug saat menggunakan strategi Gitflow. Membuat permintaan gabungan ke `bugfix` cabang secara otomatis memulai pembuatan.

1. Gunakan [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) untuk memindai informasi sensitif

1. Lint kode sumber

1. Membangun dan mengkompilasi kode sumber, jika berlaku

1. Lakukan pengujian unit

1. Lakukan analisis cakupan kode

1. Lakukan analisis kode statis

1. Membangun IAc

1. Lakukan analisis keamanan IAc

1. Ekstrak lisensi open source

## Langkah-langkah penyebaran
<a name="deployment-steps"></a>

Secara otomatis memulai penerapan `release` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) di lingkungan pengujian setelah penerapan di lingkungan pengembangan. Berikut ini adalah langkah-langkah penerapan di lingkungan pengujian:

1. Menyebarkan `release` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) di lingkungan pengujian

1. Jeda untuk persetujuan manual oleh personel yang ditunjuk

1. Unduh artefak yang diterbitkan

1. Lakukan pembuatan versi database

1. Lakukan penyebaran IAc

1. Lakukan tes integrasi

1. Lakukan tes kinerja

1. Persetujuan jaminan kualitas

## Harapan sebelum pindah ke lingkungan pementasan
<a name="expectations-before-moving-to-the-staging-environment"></a>
+ Tim pengembangan dan QA telah melakukan pengujian yang cukup untuk memenuhi kebutuhan organisasi Anda.
+ Tim pengembangan telah menyelesaikan bug yang ditemukan melalui `bugfix` cabang.

# Lingkungan pementasan
<a name="staging-environment"></a>

*Lingkungan pementasan* dikonfigurasi agar sama dengan lingkungan produksi. Misalnya, pengaturan data harus serupa dalam ruang lingkup dan ukuran dengan beban kerja produksi. Gunakan lingkungan pementasan untuk memverifikasi bahwa kode dan infrastruktur beroperasi seperti yang diharapkan. Lingkungan ini juga merupakan pilihan yang lebih disukai untuk kasus penggunaan bisnis, seperti pratinjau atau demonstrasi pelanggan.

## Akses
<a name="access"></a>

Tetapkan izin sesuai dengan prinsip hak istimewa paling sedikit. Pengembang harus memiliki akses yang sama ke lingkungan pementasan seperti yang mereka lakukan pada lingkungan produksi.

## Membangun langkah
<a name="build-steps"></a>

Tidak ada. Artefak yang sama yang digunakan dalam lingkungan pengujian digunakan kembali di lingkungan pementasan.

## Langkah-langkah penyebaran
<a name="deployment-steps"></a>

Secara otomatis memulai penerapan `release` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) di lingkungan pementasan setelah persetujuan dan penerapan di lingkungan pengujian. Berikut ini adalah langkah-langkah penerapan di lingkungan pementasan:

1. Menyebarkan `release` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) di lingkungan pementasan

1. Jeda untuk persetujuan manual oleh personel yang ditunjuk

1. Unduh artefak yang diterbitkan

1. Lakukan pembuatan versi database

1. Lakukan penyebaran IAc

1. (Opsional) Lakukan pengujian integrasi

1. (Opsional) Lakukan pengujian beban

1. Dapatkan persetujuan dari pemberi persetujuan pengembangan, QA, produk, atau bisnis yang diperlukan

## Harapan sebelum pindah ke lingkungan produksi
<a name="expectations-before-moving-to-the-production-environment"></a>
+ Rilis setara produksi telah berhasil diterapkan ke lingkungan pementasan
+ (Opsional) Integrasi dan pengujian beban berhasil

# Lingkungan produksi
<a name="production-environment"></a>

*Lingkungan produksi* mendukung produk yang dirilis, menangani data nyata oleh klien nyata. Ini adalah lingkungan yang dilindungi yang diberi akses dengan hak istimewa paling sedikit dan akses yang ditinggikan hanya boleh diizinkan melalui proses pengecualian yang diaudit untuk jangka waktu terbatas.

## Akses
<a name="access"></a>

Di lingkungan produksi, pengembang harus memiliki akses terbatas dan hanya-baca di AWS Management Console. Misalnya, pengembang harus dapat mengakses data log untuk day-to-day operasi. Semua rilis ke produksi harus dipastikan dengan langkah persetujuan sebelum penerapan.

## Membangun langkah
<a name="build-steps"></a>

Tidak ada. Artefak yang sama yang digunakan dalam lingkungan pengujian dan pementasan digunakan kembali di lingkungan produksi.

## Langkah-langkah penyebaran
<a name="deployment-steps"></a>

Secara otomatis memulai penerapan `release` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) di lingkungan produksi setelah persetujuan dan penerapan di lingkungan pementasan. Berikut ini adalah langkah-langkah penerapan di lingkungan produksi:

1. Menyebarkan `release` cabang (Gitflow) atau `main` cabang (Trunk atau GitHub Flow) di lingkungan produksi

1. Jeda untuk persetujuan manual oleh personel yang ditunjuk

1. Unduh artefak yang diterbitkan

1. Lakukan pembuatan versi database

1. Lakukan penyebaran IAc