Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Untuk aplikasi produksi, Anda harus menyiapkan alur kerja pengembangan yang jelas, terutama jika ada lebih dari satu orang yang mengerjakan aplikasi Anda. Alur kerja pengembangan biasanya melibatkan penyiapan dan pengelolaan beberapa lingkungan.
Firebase memiliki berbagai tingkat dukungan untuk alur kerja developer dan lingkungan konstituen. Setelah Anda memahami istilah dan asumsi alur kerja developer di halaman ini, baca artikel praktik terbaik umum dan pedoman keamanan umum untuk menyiapkan project Firebase dan aplikasi Anda.
Tentang lingkungan
Dalam pengembangan software, lingkungan adalah semua hardware dan software
yang diperlukan untuk menjalankan instance dari aplikasi atau sistem aplikasi.
Serangkaian lingkungan memberikan isolasi untuk pengembangan dan pengujian software
tanpa memengaruhi pengguna. Seperti yang ditunjukkan pada diagram di bawah, lingkungan pada tingkat tinggi dianggap sebagai praproduksi atau produksi, dan Anda dapat memiliki lingkungan produksi sesuai kebutuhan. Diagram juga menjelaskan praktik dan fitur umum yang terkait dengan setiap jenis lingkungan.
Proses pengembangan fitur atau rilis ke produksi melalui lingkungan ini disebut pipeline deployment.
Jenis lingkungan
Lingkungan terdiri dari infrastruktur yang mendasari yang Anda perlukan untuk menjalankan dan mendukung aplikasi Anda, kodenya, serta datanya. Luaskan setiap istilah berikut untuk meninjau deskripsi beberapa lingkungan umum, termasuk tips tentang jenis data yang digunakan di setiap jenis lingkungan.
Lingkungan pengembangan (dev)
Setiap developer membutuhkan lingkungan pengembangan, yakni tempat yang aman dan terisolasi untuk menguji perubahan yang sedang di-build. Idealnya, setiap developer di tim Anda memiliki akses
ke lingkungan pengembangan mereka sendiri. Selain itu, jika lingkungan pengembangan adalah instance lokal, developer dapat melakukan iterasi dengan lebih cepat.
Data dalam lingkungan pengembangan disematkan dengan data yang biasanya menyerupai data produksi, tetapi tidak boleh berisi data pengguna yang sebenarnya. File ini mungkin juga berisi data yang telah menyebabkan bug di masa lalu, seperti string yang sangat panjang.
Lingkungan pengujian dan QA
Jika memiliki pengujian otomatis, Anda memerlukan lingkungan untuk menjalankan pengujian tersebut, dan Anda harus mereset data setiap kali menyiapkan lingkungan pengujian.
Jika Anda memiliki engineer QA, mereka mungkin memerlukan satu lingkungan yang semuanya digunakan, atau mereka mungkin memerlukan lingkungan individual untuk menguji kandidat rilis baru.
Data di lingkungan pengujian dan QA dibekali dengan data berkualitas yang
umumnya mewakili data produksi, beserta data yang mewakili
kasus patologikal dan contoh data yang telah menyebabkan bug di masa lalu.
Lingkungan staging
Untuk menguji secara realistis cara kerja rilis dalam produksi, Anda memerlukan lingkungan staging yang meniru infrastruktur produksi sedekat mungkin. Sangatlah umum untuk memiliki beberapa instance staging jika Anda perlu menguji integrasi tertentu secara terpisah.
Berikut perbedaan umum antara staging dan produksi:
Staging mungkin tidak memiliki beberapa fitur atau integrasi yang dapat menyebabkan efek samping. Misalnya, staging dapat disetel untuk tidak mengirim email.
Staging mungkin memiliki data anonim; data tersebut bisa palsu, tetapi harus realistis. Karena staging adalah tempat untuk men-debug masalah dengan aman, Anda dapat memberi tim akses yang lebih luas ke data staging daripada data produksi. Jadi, untuk melindungi privasi
pengguna, Anda tidak boleh menggunakan data pengguna yang sebenarnya dalam staging.
Lingkungan produksi (prod)
Untuk setiap aplikasi yang Anda pertahankan, Anda memerlukan satu lingkungan produksi. Ini adalah instance yang digunakan pengguna Anda untuk berinteraksi.
Tidak seperti lingkungan lain yang dapat Anda gunakan untuk mengubah, menghapus, dan/atau membuat ulang data, data dalam lingkungan produksi Anda sangat penting. Jika
data produksi hilang atau berubah, dampaknya akan terasa langsung pada pengguna.
Di Firebase console, sebaiknya beri tag pada project Firebase yang terkait dengan lingkungan produksi Anda sebagai jenis lingkungan "produksi". Tag ini
dapat membantu mengingatkan Anda dan rekan kerja bahwa perubahan apa pun dapat memengaruhi
aplikasi produksi terkait dan datanya.
Langkah berikutnya
Tinjau praktik terbaik umum kami untuk menyiapkan project Firebase. Panduan ini menjawab pertanyaan tentang hierarki project Firebase, cara mendaftarkan varian aplikasi, dan multi-tenancy.
Tinjau pedoman keamanan umum untuk lingkungan yang berbeda. Anda ingin memastikan setiap lingkungan dan datanya aman.
[null,null,["Terakhir diperbarui pada 2025-08-04 UTC."],[],[],null,["For production apps, you need to set up a clear development workflow, especially\nif you have more than one person working on your app. A development workflow\nusually involves setting up and managing multiple environments.\n\nFirebase has varying levels of support for developer workflows and the\nconstituent environments. Once you're familiar with the developer workflow terms\nand assumptions on this page, check out our\n[general best practices](/docs/projects/dev-workflows/general-best-practices)\nand\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\nfor setting up a Firebase project and your apps.\n| **Key Point:** We recommend reading our guides thoroughly, but here's the top takeaway about development workflows: \n| **Firebase recommends using a *separate* Firebase project for *each* environment\n| in your development workflow.**\n\nAbout environments\n\nIn software development, an ***environment*** is all the hardware and software\nthat are required to run an instance of an application or system of\napplications.\n\nA series of environments provides isolation for developing and testing software\nwithout impacting users. As shown in the diagram below, environments at a\nhigh-level are considered either *pre-production* or *production* , and you can\nhave as many pre-production environments as needed. The diagram also describes\ncommon practices and features associated with each\n[type of environment](#types).\n\nThe process of progressing a feature or release through these environments to\nproduction is called a ***deployment pipeline***.\n\nTypes of environments\n\nAn environment is composed of the underlying infrastructure that you need to run\nand support your application, its code, and its data. Expand each of the\nfollowing terms to review descriptions of some common environments, including\ntips on the types of data used in each environment type.\n| **Key Point:** Every app should have at least one *pre-production* environment that's isolated from production data and resources.\n\n\u003cbr /\u003e\n\n**Development (dev) environments**\n\n\u003cbr /\u003e\n\nEvery developer needs a development environment --- a safe, isolated place to test\nchanges as they're being built. Ideally, every developer on your team has access\nto their own dev environment. Also, if the dev environment is a local instance,\na developer can iterate much faster.\n\nThe data in a dev environment is seeded with data that generally resembles the\nproduction data, but should never contain any real users' data. It may also\ncontain data that has caused bugs in the past, like very long strings.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Test and QA environments**\n\n\u003cbr /\u003e\n\nIf you have automated tests, you need an environment in which to run those\ntests, and you need to reset the data each time you spin up the test\nenvironment.\n\nIf you have QA engineers, they may need one environment that they all use, or\nthey may need individual environments to test a new release candidate.\n\nThe data in test and QA environments is seeded with quality data that's\ngenerally representative of the production data, along with data that represents\ncorner cases and examples of data that have caused bugs in the past.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Staging environments**\n\n\u003cbr /\u003e\n\nFor realistic tests of how a release will work in production, you need a staging\nenvironment that mimics production infrastructure as closely as possible. It's\ncommon to have multiple staging instances if you need to test specific\nintegrations in isolation.\n\nHere are common differences between staging and prod:\n\n- Staging may be missing some features or integrations that could cause side\n effects. For example, staging may be set to not send email.\n\n- Staging may have anonymized data; the data can be fake, but it should be\n realistic. Because staging is a place to safely debug problems, you might give\n broader team access to staging data than production data. So, to protect user\n privacy, you shouldn't use actual user data in staging.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Production (prod) environments**\n\n\u003cbr /\u003e\n\nFor each application that you maintain, you need a single production\nenvironment. This is the instance with which your users interact.\n\nUnlike the other environments where you can change, delete, and/or recreate\ndata, the data in your prod environment is very important; losing or altering\nyour prod data will directly affect your users.\n\nIn the Firebase console, we recommend tagging the Firebase project associated\nwith your production environment as a\n[\"production\" environment type](/support/faq#set-environment-type). This tag\ncan help remind you and your teammates that any changes could affect your\nassociated production apps and their data.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n| **Tip** : Integrations with analytics services, including Google Analytics, often require special attention when you're setting up a new environment. You also don't want your tests from pre-production environments to impact production analytics.\n|\n| We recommend not setting up analytics for most pre-production environments,\n| unless you want to specifically test analytics integrations, like making\n| sure the right parameters are being sent to your analytics service.\n\nNext steps\n\n- Review our [general best practices](/docs/projects/dev-workflows/general-best-practices)\n for setting up Firebase projects. This guide answers questions about Firebase\n project hierarchy, how to register your app variants, and multi-tenancy.\n\n- Review the [general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\n for different environments. You want to make sure each environment and its\n data are secure.\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]