软件开发里的各种环境（转载）

先看网友对这个问题的看法，集思广益。

 

 

下面是转载的一片好文章，讲的很清楚，细细品读吧！

 

原文地址：http://www.dotkernel.com/php-development/php-environment-development-staging-production/

In hosted software development, the environment refers to a server tier designated to a specific stage in a release process. The purpose of these environments is to improve the development, testing and release processes in client-server applications. The most common environments are described below.

Development
This is where the software is developed – it’s the working environment for individual developers or small teams. The purpose of this environment is for the developer to work on local host, separate from the rest of the team, allowing them to make various changes without worrying that it may alter the work of the other members of the team.

Staging
It is used to assemble, test and review the application before it goes into production. Usually the staging environment tries to simulate as much as possible the production environment (hardware and software-wise). Normally, before releasing an update version of the application on the production environment, the update must be tested on the staging environment. This environment can also be used as a demonstration/training environment.

Production
It is the “live” environment, where the final application goes out to the world and becomes active.

To switch from one environment to another use the Subversion source code.

Using SVN on Aptana is an article that explains how to set your development environment on your local computer and then to change it on your staging environment.

To better understand the development of an application using environments, check this helpful article http://dltj.org/article/software-development-practice/

This entry was posted in PHP Development. Bookmark the permalink.

Using LIKE wildcards with Zend_Db →← DotKernel 1.2.2 release

 

 

另外又在网上找到了一张图，讲述了软件开发的流程，并附有相关说明，请看：

In narrative form, the software developer writes code in his or her development environment (1) and checks it into the Subversion source code repository (2). As other developers report bugs (3) more changes are made (5) and checked in (6). Remember that the Development and Integration environments can be the same actual environment, so these two boxes can be collapsed; it is important to note, though, that in such a case changes are still being checked into Subversion.

 

When the developers are happy with the behavior of the Integration environment (6), the Release Master creates a copy or “tag” of the code in Subversion and updates the Staging environment to this tag (7). At this point the quality assurance (QA) testers start their review (8). QA testers can be both internal staff and external reviewers; the Staging area also doubles as a training environment when the Production release is ready. QA reports go back to the developer (9) who fixes them (10) and checks the changes into Subversion (11). After all of the bugs are fixed, the release manager promotes a new version to staging (12).

 

This process continues until the QA team declares the staging version is “okay to release” (13). The release manager packages up the release version from Subversion (14) and deploys it on the production servers (15). As time goes on, bug reports and feature requests are made (16) for which the developer writes code (17) and checks in the changes to the source code repository (18). (17) and (18) are functionally equivalent to ”(1)” and ”(2)” above. Repeat until the end user is completely satisfied.