I've worked in many companies, each one with a different set of environments, the one I have like the most had 5 environments:
1) Local: Basically your machine. Here is where you code and test your changes before even asking a peer for review.
2) Dev: If for some reason you cannot test your code locally (Dependencies issues mainly: "My code has neves compiled in my machine but it compiles perfectly in Jenkins/Bamboo/Travis"), then you push your changes to your feature branch in Git and make Bamboo compile it and deploy it to a dev server where you can test (you are still not sure if it will work, so no peer review so far).
3) Staging: You think your code work and you love how it looks like. You create a Pull Request in order for you peers to take a look at it before it gets merged to the master branch. Here they make comments and you fix possible issues, since you are more sure about your changes you make Bamboo deploy it to the Staging environment where more "stable" code lives and more realistic data is stored in whatever database is there. Once deployed another developer/tester can check your changes actually work and make you a "QA Sign off in Staging Env."
4) Stable: Ok, now you are ultimate sure your changes work since you deployed to Staging and nothing got broken. You merge your branch to master and Bamboo compiles master and deploys to another sets of servers in a Stable Environment (no one else should merge to master until you finish your deployment to Production, to avoid a merge of not related merges). This environment should be a replica from Production, data, code and server conditions. Here is where you show your changes to your manager, product owner or the person in charge to validate your work before sending it to production. You get the final approval, everything is good, you are sweaty, you have worked for 30 days in a row to get this change done, your wife divorced you but you are very confident it works perfectly.
5) Production: Where the clients connect to consume the company services, or the final build of your software to send to customers. With a few clicks in Bamboo you make it deploy to Production servers or compile the final build. It is green, everything seems to be ok. You check Splunk looking for errors, everything is good, life is good, you drink another sip of coffee before leaving, you drive home and sleep all weekend with your dog by your side.
It's a happy ending because having so many "Test" environments ensure quality, no change gets to production until EVERYBODY (not just you) are completely sure that changes is working.
At our company there are two databases too, a test and a production database. The test database is mainly used for testing by developers but sometimes for business tests too. This database is refreshed daily using an actual copy of the production database. So this database can be both a playground and a serious testing database. But a third, development, database is the best option. We had one, but it is broken at the moment. But when you get one of those, you should make sure it is refreshed often enough. When developers use it as a playground, it will stray away from the production environment, and its data will be both old and currupt. Because of this, developers won't be able to test well themselves. So make sure you refresh this database periodically (maybe daily too, or at least once a week).
If possible, give each developer their own database on their local machine. That way they can do whatever they want with it without affecting anyone else. This should significantly decrease the desire to play with the test database, providing a more stable environment for business UAT.
I believe in order to establish an environment strategy that supports all ALM/SDLC activities 4 requirements should exist:
1) Development environment: to allow Dev to play around with new code/concepts and typically unit test with some basic integration testing using stubs and drivers. This environment should have loose change control procedures and would typically not be anywhere near the same scale as production. This is where the Dev team can build and tear down setups as required.
2) Interop environment: where integration of systems can be further tested and increased capability for non-functional testing I.e might be a resilient env with greater scalability than Dev. I'd see this environment having tighter change control and management. Test would perform integration and system testing in this environment.
3) Reference Architecture: This is what some might call pre-prod but is essentially the same as production in terms of scale and resilience. This would have change control and management procedures akin to prod. This env would support further test activities especially full scale performance testing, failover as well as operational fault triage and maintenance activities once a product is launched to customers.
4) Production: This environment will support live customers and so test activities will be limited once this is the case. This will be fully managed and have strict change management and config management processes.
You could give each developer the latest database docker image to play on their local environment. If the data is corrupted, they can just recreate the container.
发布评论
评论（5）
我在很多公司工作过，每个公司都有不同的环境，我最喜欢的公司有 5 个环境：
1) 本地：基本上是你的机器。您可以在此处编码并测试您的更改，然后再请求同行评审。
2）开发：如果由于某种原因你无法在本地测试你的代码（主要是依赖关系问题：“我的代码在我的机器上编译了，但它在 Jenkins/Bamboo/Travis 中完美编译”），那么你将更改推送到你的功能分支在 Git 中并让 Bamboo 对其进行编译并将其部署到可以测试的开发服务器（您仍然不确定它是否会工作，因此到目前为止还没有同行评审）。
3) 暂存：您认为您的代码可以工作并且您喜欢它的外观。您创建一个拉取请求，以便您的同行在将其合并到主分支之前查看它。他们在这里发表评论，您修复可能的问题，因为您对自己的更改更加确定，因此您可以将 Bamboo 部署到暂存环境，在暂存环境中存在更多“稳定”代码，并且更真实的数据存储在任何数据库中。部署后，另一位开发人员/测试人员可以检查您的更改是否实际工作，并使您“在暂存环境中进行 QA 签核”。
4) 稳定：好的，现在您完全确定您的更改有效，因为您部署到了 Staging 并且没有任何问题。您将分支合并到 master，Bamboo 编译 master 并部署到稳定环境中的另一组服务器（在完成到生产的部署之前，其他人不应合并到 master，以避免合并不相关的合并）。该环境应该是生产、数据、代码和服务器条件的副本。您可以在此处向经理、产品负责人或负责人展示您的更改，以便在将其投入生产之前验证您的工作。你得到了最终的批准，一切都很好，你满头大汗，你连续工作了30天才完成这个改变，你的妻子和你离婚了，但你非常有信心它完美地运作。
5) 生产：客户连接以使用公司服务，或将软件的最终版本发送给客户。只需在 Bamboo 中单击几下，即可将其部署到生产服务器或编译最终版本。是绿色的，一切似乎都很好。你检查 Splunk 寻找错误，一切都很好，生活很美好，你在离开前又喝了一口咖啡，你开车回家，整个周末都和你的狗一起睡觉。
这是一个皆大欢喜的结局，因为有如此多的“测试”环境可以确保质量，直到每个人（不仅仅是您）完全确定更改正在发挥作用之前，不会对生产进行任何更改。
I've worked in many companies, each one with a different set of environments, the one I have like the most had 5 environments:
1) Local: Basically your machine. Here is where you code and test your changes before even asking a peer for review.
2) Dev: If for some reason you cannot test your code locally (Dependencies issues mainly: "My code has neves compiled in my machine but it compiles perfectly in Jenkins/Bamboo/Travis"), then you push your changes to your feature branch in Git and make Bamboo compile it and deploy it to a dev server where you can test (you are still not sure if it will work, so no peer review so far).
3) Staging: You think your code work and you love how it looks like. You create a Pull Request in order for you peers to take a look at it before it gets merged to the master branch. Here they make comments and you fix possible issues, since you are more sure about your changes you make Bamboo deploy it to the Staging environment where more "stable" code lives and more realistic data is stored in whatever database is there. Once deployed another developer/tester can check your changes actually work and make you a "QA Sign off in Staging Env."
4) Stable: Ok, now you are ultimate sure your changes work since you deployed to Staging and nothing got broken. You merge your branch to master and Bamboo compiles master and deploys to another sets of servers in a Stable Environment (no one else should merge to master until you finish your deployment to Production, to avoid a merge of not related merges). This environment should be a replica from Production, data, code and server conditions. Here is where you show your changes to your manager, product owner or the person in charge to validate your work before sending it to production. You get the final approval, everything is good, you are sweaty, you have worked for 30 days in a row to get this change done, your wife divorced you but you are very confident it works perfectly.
5) Production: Where the clients connect to consume the company services, or the final build of your software to send to customers. With a few clicks in Bamboo you make it deploy to Production servers or compile the final build. It is green, everything seems to be ok. You check Splunk looking for errors, everything is good, life is good, you drink another sip of coffee before leaving, you drive home and sleep all weekend with your dog by your side.
It's a happy ending because having so many "Test" environments ensure quality, no change gets to production until EVERYBODY (not just you) are completely sure that changes is working.
我们公司也有两个数据库，一个测试数据库和一个生产数据库。测试数据库主要用于开发人员测试，有时也用于业务测试。该数据库每天使用生产数据库的实际副本进行刷新。所以这个数据库既可以是一个游乐场，也可以是一个严肃的测试数据库。但第三个，开发数据库是最好的选择。我们有一个，但现在坏了。但当你得到其中之一时，你应该确保它足够频繁地刷新。当开发人员将其用作游乐场时，它将偏离生产环境，并且其数据将是陈旧且损坏的。因此，开发人员将无法自己进行良好的测试。因此，请确保定期刷新此数据库（也可以每天刷新，或至少每周刷新一次）。
At our company there are two databases too, a test and a production database. The test database is mainly used for testing by developers but sometimes for business tests too. This database is refreshed daily using an actual copy of the production database. So this database can be both a playground and a serious testing database. But a third, development, database is the best option. We had one, but it is broken at the moment. But when you get one of those, you should make sure it is refreshed often enough. When developers use it as a playground, it will stray away from the production environment, and its data will be both old and currupt. Because of this, developers won't be able to test well themselves. So make sure you refresh this database periodically (maybe daily too, or at least once a week).
如果可能，请为每个开发人员在其本地计算机上提供自己的数据库。这样他们就可以用它做任何他们想做的事情，而不会影响其他任何人。这应该会显着降低使用测试数据库的欲望，为业务 UAT 提供更稳定的环境。
If possible, give each developer their own database on their local machine. That way they can do whatever they want with it without affecting anyone else. This should significantly decrease the desire to play with the test database, providing a more stable environment for business UAT.
我相信，为了建立支持所有 ALM/SDLC 活动的环境策略，应该存在 4 个要求：
1) 开发环境：允许开发人员使用新代码/概念，通常使用存根和驱动程序进行一些基本集成测试的单元测试。该环境应该具有宽松的变更控制程序，并且通常不会达到与生产相同的规模。开发团队可以根据需要构建和拆除设置。
2) 互操作环境：可以进一步测试系统的集成并增加非功能测试的能力，即可能是一个具有比 Dev 更大的可扩展性的弹性环境。我认为这种环境具有更严格的变更控制和管理。测试将在此环境中执行集成和系统测试。
3) 参考架构：有些人可能将其称为预生产，但在规模和弹性方面与生产本质上相同。这将具有类似于产品的变更控制和管理程序。该环境将支持进一步的测试活动，特别是产品向客户推出后的全面性能测试、故障转移以及操作故障分类和维护活动。
4) 生产：此环境将支持现场客户，因此一旦出现这种情况，测试活动将受到限制。这将得到全面管理，并具有严格的变更管理和配置管理流程。
希望这有帮助
I believe in order to establish an environment strategy that supports all ALM/SDLC activities 4 requirements should exist:
1) Development environment: to allow Dev to play around with new code/concepts and typically unit test with some basic integration testing using stubs and drivers. This environment should have loose change control procedures and would typically not be anywhere near the same scale as production. This is where the Dev team can build and tear down setups as required.
2) Interop environment: where integration of systems can be further tested and increased capability for non-functional testing I.e might be a resilient env with greater scalability than Dev. I'd see this environment having tighter change control and management. Test would perform integration and system testing in this environment.
3) Reference Architecture: This is what some might call pre-prod but is essentially the same as production in terms of scale and resilience. This would have change control and management procedures akin to prod. This env would support further test activities especially full scale performance testing, failover as well as operational fault triage and maintenance activities once a product is launched to customers.
4) Production: This environment will support live customers and so test activities will be limited once this is the case. This will be fully managed and have strict change management and config management processes.
Hope this helps
您可以为每个开发人员提供最新的数据库 Docker 映像，以便在他们的本地环境中使用。如果数据损坏，他们只需重新创建容器即可。
You could give each developer the latest database docker image to play on their local environment. If the data is corrupted, they can just recreate the container.