Lingkungan di Serverless Application Center mengisolasi penerapan aplikasi di berbagai wilayah, virtual private cloud (VPC), dan konfigurasi resource. Anda dapat menerapkan layanan dalam lingkungan terisolasi untuk mencapai ketersediaan tinggi atau latensi rendah bagi layanan produksi. Setiap lingkungan membatasi cakupan resource seperti Simple Log Service (SLS), VPC, dan File Storage NAS (NAS) secara independen, sehingga beban kerja pengembangan, pengujian, dan produksi tidak tumpang tindih. Aturan pipeline yang berbeda dapat dikaitkan dengan setiap lingkungan—misalnya, commit ke branch pengembangan memicu continuous integration (CI) di lingkungan pengujian, sedangkan merge ke branch utama memicu rilis di lingkungan produksi.
Sebelum memulai
Secara default, tidak ada nama domain yang ditetapkan untuk suatu lingkungan. Untuk menggunakan nama domain berbeda pada lingkungan berbeda, tentukan bidang
customDomainsdalam files.yamlrepositori Anda.Menghosting resource Alibaba Cloud (SLS, VPC, NAS) dalam suatu lingkungan memerlukan izin layanan yang sesuai. Lampirkan kebijakan yang diperlukan ke peran
AliyunFCServerlessDevsRole.Satu layanan dapat diterapkan di beberapa lingkungan. Anda dapat menentukan apakah akan menggunakan konfigurasi yang disediakan oleh lingkungan tersebut.
Buat lingkungan
Masuk ke Konsol Function Compute dan buka halaman detail aplikasi.
Klik Create Environment.

Konfigurasikan parameter berikut:
Parameter Deskripsi Environment Name Nama deskriptif untuk membedakan lingkungan ini. Satu jenis lingkungan dapat memiliki beberapa lingkungan bernama. Environment Type Kategori untuk penyaringan: test, staging, atau production. Description Informasi dasar seperti wilayah dan nama peran. Pengaturan wilayah, logging, jaringan, dan penyimpanan yang ditentukan di sini menggantikan konfigurasi dalam file s.yaml. Misalnya, jikas.yamlmenentukan China (Hangzhou) tetapi lingkungan diatur ke China (Beijing), resource akan diterapkan di China (Beijing).Pipeline Configurations Setiap lingkungan dipetakan ke satu pipeline secara default. Konfigurasikan pemicu pipeline dan langkah build di sini.
Pemetaan branch ke lingkungan
Alur kerja yang direkomendasikan memetakan satu branch ke satu pipeline ke satu lingkungan:
| Branch | Lingkungan | Pemicu |
|---|---|---|
dev | Development | Commit ke dev |
test | Test | Commit ke test |
main / master | Production | Merge ke main |
Gunakan pull request (PR) atau merge request (MR) untuk mempromosikan kode dari branch pengembangan ke branch pengujian, lalu ke branch utama.
Dalam beberapa skenario, beberapa aplikasi berbagi codebase yang sama untuk pengguna berbeda. Satu branch dapat memicu beberapa pipeline, memperbarui beberapa lingkungan dalam satu commit.
Lihat detail lingkungan
Masuk ke Konsol Function Compute.
Di panel navigasi sebelah kiri, klik Applications.
Di halaman Applications, temukan aplikasi Anda dan klik ikon expand di sisi kiri untuk menampilkan daftar lingkungannya.
Klik nama lingkungan untuk membuka tab Environment Details. Tab ini juga menyediakan akses ke pengembangan berbasis cloud dan konfigurasi pipeline.
Informasi dasar
Konfigurasi sumber kode
Deployment History
Sumber Daya
Roll back lingkungan
Roll back hanya memengaruhi kode bisnis aplikasi. Dependensi hulu dan hilir—seperti database—tidak di-rollback. Misalnya, jika aplikasi Anda tidak dapat terhubung ke database karena kesalahan, roll back kode aplikasi saja tidak menyelesaikan masalah tersebut.
Roll back menerapkan ulang kode dan konfigurasi resource (misalnya, file s.yaml) yang diambil dari snapshot penerapan sebelumnya.
Buka tab Environment Details untuk lingkungan target.
Di bagian Deployment History, klik Roll Back di sebelah penerapan yang ingin Anda pulihkan.

Kelola resource
Serverless Application Center menampilkan informasi binding resource dalam mode read-only. Untuk mengelola resource, gunakan file s.yaml di repositori kode Anda, bukan mengubah pengaturan langsung di halaman manajemen resource.
Perubahan yang dilakukan di halaman manajemen resource tanpa pembaruan yang sesuai pada file s.yaml akan ditimpa pada penerapan pipeline berikutnya. Misalnya, jika s.yaml menetapkan memori fungsi menjadi 1.024 MB dan developer mengubahnya menjadi 2.048 MB di halaman manajemen, penerapan pipeline berikutnya akan mengembalikan memori ke 1.024 MB.
Kembangkan di cloud
Di halaman detail aplikasi, klik Cloud Development.
Klik Initialize Code Repository untuk menyiapkan lingkungan kode.
Setelah inisialisasi, gunakan WebIDE untuk melihat, mengedit, dan men-debug kode.
Dorong perubahan ke repositori menggunakan salah satu metode berikut:
Gunakan terminal bawaan atau plugin Git.
Klik Save Code to Repository di pojok kiri atas untuk menambahkan, commit, dan dorong dalam satu langkah.

Konfigurasi pipeline
Untuk detail konfigurasi pipeline, lihat Kelola pipeline.
Hapus lingkungan
Masuk ke Konsol Function Compute.
Di panel navigasi sebelah kiri, klik Applications.
Temukan lingkungan yang akan dihapus dan klik Delete di kolom Actions.
Di dialog konfirmasi, tinjau daftar resource. Kosongkan kotak centang di samping resource apa pun yang ingin Anda pertahankan.
Menghapus lingkungan juga dapat menghapus resource terkaitnya. Verifikasi nama dan jenis resource sebelum mengonfirmasi.

Isolasi layanan di berbagai lingkungan
Serverless Application Center mengikuti model GitOps: repositori Git adalah satu-satunya sumber kebenaran untuk status aplikasi, dan file YAML yang mengikuti spesifikasi YAML Serverless Devs menggerakkan penerapan.
Di banyak lingkungan enterprise, peran R&D dan O&M memiliki tanggung jawab yang berbeda. Tim O&M mengelola infrastruktur dan memberi otorisasi kepada developer untuk menggunakannya. Tim R&D mengelola kode aplikasi. Jika seluruh infrastruktur dikelola dalam repositori Git, personel O&M harus mengirimkan kode untuk mengubah infrastruktur, yang bertentangan dengan alur kerja sebagian besar engineer O&M. Metode penerapan berikut mengatasi pemisahan ini pada skala yang berbeda.
Metode 1: File YAML terpisah per lingkungan
Pertahankan file YAML khusus untuk setiap lingkungan dan arahkan setiap pipeline ke file yang sesuai.

Untuk mengurangi duplikasi di berbagai file YAML, gunakan YAML inheritance di Serverless Devs.
Metode 2: YAML bersama dengan variabel lingkungan pipeline
Gunakan satu file YAML dan sisipkan nilai khusus lingkungan melalui variabel lingkungan pipeline menggunakan sintaks ${env(VAR_NAME)}.
vars:
region: ${env(region)}
service:
name: demo-service-${env(prefix)}
internetAccess: true
logConfig:
project: ${env(LOG_PROJECT)}
logstore: fc-console-function-pre
vpcConfig:
securityGroupId: ${env(SG_ID)}
vswitchIds:
- ${env(VSWITCH_ID)}
vpcId: ${env(VPC_ID)}Untuk petunjuk menyetel variabel lingkungan pipeline, lihat bagian "Pipeline environment variables" dalam Kelola pipeline.
Metode 3: YAML bersama dengan output resource lingkungan
Gunakan satu file YAML dan referensikan resource yang terikat ke setiap lingkungan melalui sintaks ${environment.outputs.XXX}.
service:
logConfig:
project: ${environment.outputs.slsProject}
logstore: ${environment.outputs.slsLogStore}
vpcConfig:
vpcId: ${environment.outputs.vpcId}
securityGroupId: ${environment.outputs.securityGroupId}
vswitchIds:
- ${environment.outputs.vswitchId}
nasConfig:
userId: 10003
groupId: 10003
mountPoints:
- serverAddr: ${environment.outputs.nasMountTargetId}
nasDir: /fc-deploy-service
fcDir: /mnt/autoPilih metode
| Metode | Paling cocok untuk | Kelebihan | Kekurangan |
|---|---|---|---|
| 1 – File YAML terpisah | Tim kecil di mana semua anggota mengelola file YAML secara langsung | Paling sederhana; setiap lingkungan sepenuhnya mandiri | Duplikasi YAML di berbagai lingkungan |
| 2 – Variabel lingkungan pipeline | Tim dengan peran R&D dan O&M yang terpisah serta jumlah lingkungan yang sedikit | Pemisahan tanggung jawab yang jelas; O&M mengelola variabel, R&D mengelola kode | Sulit diskalakan saat infrastruktur semakin besar |
| 3 – Output resource lingkungan | Alur kerja serverless modern dengan lingkungan dinamis | Mendukung provisioning resource on-demand; lingkungan dapat dibuat dan dihapus otomatis selama CI; izin resource produksi dapat diberikan ke R&D sesuai kebutuhan | Memerlukan lingkungan yang telah dikonfigurasi sebelumnya dengan binding resource |