Python 2.7 telah mencapai akhir dukungan
dan akan
dihentikan penggunaannya
pada 31 Januari 2026. Setelah penghentian penggunaan, Anda tidak akan dapat men-deploy aplikasi Python 2.7, meskipun organisasi Anda sebelumnya menggunakan kebijakan organisasi untuk mengaktifkan kembali deployment runtime lama. Aplikasi Python 2.7 yang ada akan terus berjalan dan menerima traffic setelah
tanggal penghentiannya. Sebaiknya Anda
bermigrasi ke versi Python terbaru yang didukung.
Penamaan Lingkungan Developer
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Project software berbasis cloud harus menggunakan beberapa lingkungan. Lingkungan ini biasanya memiliki nama seperti dev, qa, staging, dan prod.
Lingkungan ini harus terisolasi sepenuhnya satu sama lain, dan biasanya memiliki izin akses operator yang sangat berbeda.
Misalnya, tim pengembangan mungkin memiliki akses penuh ke lingkungan dev, tetapi hanya akses terbatas ke lingkungan prod, dengan semua deployment kode yang hanya didorong oleh skrip otomatis. Selain itu, sangat penting untuk menjaga agar data di lingkungan yang berbeda tetap terisolasi.
Penggunaan beberapa projectGoogle Cloud sangat sesuai dengan persyaratan ini karena project tersebut menyediakan pemisahan kode dan data secara menyeluruh, serta izin operator dapat dikelola secara terpisah. Karena App Engine secara otomatis menskalakan instance yang menyajikan, Anda hanya membayar sesuai penggunaan. Misalnya, jika lingkungan staging Anda hanya diperlukan satu minggu dari setiap empat lingkungan, Anda tidak perlu membayar biaya instance penyajian untuk tiga lingkungan lainnya. Namun, perlu diingat bahwa Anda akan dikenai biaya untuk setiap data yang disimpan dalam project ini.
Penamaan lingkungan
Jika memilih untuk membuat aplikasi microservice dengan hanya menggunakan beberapa layanan, Anda dapat membuat satu project Google Cloud untuk setiap lingkungan dan memberikan nama yang sesuai ke lingkungan tersebut, misalnya web-app-dev, web-app-qa, dan web-app-prod.
Atau, jika memilih untuk membuat aplikasi microservice dengan menggunakan beberapa project, Anda dapat memperoleh pemisahan yang sama di antara lingkungan, tetapi Anda perlu menggunakan lebih banyak project, seperti web-app-dev, web-app-prod, user-service-dev, dan user-service-prod.
Anda harus menggunakan pola kode untuk memastikan bahwa project dev hanya memanggil project dev lain dan project prod hanya memanggil project prod lainnya.
Langkah berikutnya
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-09-04 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[[["\u003cp\u003eCloud-based projects should utilize multiple, isolated environments such as \u003ccode\u003edev\u003c/code\u003e, \u003ccode\u003eqa\u003c/code\u003e, \u003ccode\u003estaging\u003c/code\u003e, and \u003ccode\u003eprod\u003c/code\u003e, each with distinct operator-access permissions.\u003c/p\u003e\n"],["\u003cp\u003eMaintaining data isolation between environments is crucial for preventing data corruption and maintaining the integrity of each environment.\u003c/p\u003e\n"],["\u003cp\u003eUsing multiple Google Cloud projects is ideal for ensuring the isolation of code and data between environments, and managing operator permissions independently.\u003c/p\u003e\n"],["\u003cp\u003eNaming conventions for environments, whether using single or multiple Google Cloud projects, should clearly indicate the environment type, for example, \u003ccode\u003eweb-app-dev\u003c/code\u003e, \u003ccode\u003eweb-app-prod\u003c/code\u003e, \u003ccode\u003euser-service-dev\u003c/code\u003e, etc.\u003c/p\u003e\n"],["\u003cp\u003eWhen using multiple projects, specific code patterns are needed to restrict communication so that \u003ccode\u003edev\u003c/code\u003e projects only interact with other \u003ccode\u003edev\u003c/code\u003e projects, and \u003ccode\u003eprod\u003c/code\u003e projects only interact with other \u003ccode\u003eprod\u003c/code\u003e projects.\u003c/p\u003e\n"]]],[],null,["# Naming Developer Environments\n\nCloud-based software projects should employ multiple environments. These\nenvironments typically have names like `dev`, `qa`, `staging`, and `prod`.\nIt's vital that these environments be completely isolated from one another,\nand they typically have very different operator-access permissions.\nFor example, the development team might have full access to the `dev`\nenvironment, but only limited access to the `prod` environment, with all\ncode deployment driven only by automated scripts. Further, it's\nabsolutely essential that the data in the different environments stay isolated.\n\nUsing multiple [Google Cloud projects](/resource-manager/docs/creating-managing-projects) suits these requirements perfectly\nas the projects provide complete isolation of code and data, and operator\npermissions can be managed separately. Because App Engine automatically scales\nits serving instances, you only pay for what you use. For example, if your\nstaging environment is only required one week out of every four, you won't pay\nfor any serving instance costs for the other three. However, keep in mind that\nyou will be billed for any data stored in these projects.\n\nNaming environments\n-------------------\n\nIf you choose to create your microservices application by using only multiple\nservices, you can create a single Google Cloud project for each of your\nenvironments and name them accordingly, such as `web-app-dev`, `web-app-qa`,\nand `web-app-prod`.\n\nAlternatively, if you choose to create your microservices application by\nusing multiple projects, you can achieve the same separation between\nenvironments, but you'll need to use more projects, such as\n`web-app-dev`, `web-app-prod`, `user-service-dev`, and `user-service-prod`.\nYou will need to use code patterns to ensure that the `dev` projects only\ncall other `dev` projects and the `prod` projects only call\nother `prod` projects.\n\nWhat's next\n-----------\n\n- Get an overview of [microservice architecture on App Engine](/appengine/docs/legacy/standard/python/microservices-on-app-engine).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/python/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/python/microservice-performance).\n- Learn how to [Migrate an existing monolithic application to one with microservices](/appengine/docs/legacy/standard/python/microservice-migration)."]]
