当前位置： 文江博客话题详情

您如何组织服务器进行 Web 开发？

发布于 08-05 08:36 字数 238 浏览 7 评论 0原文

我正在设置一些用于网站开发的服务器。我希望它以相当标准的方式组织。您如何组织服务器来开发相对较小的网站，每个网站都有一点独特的代码？

我关心的一些细节包括（但不限于）：

  1. 在开发过程中存在哪些不同的服务器？它们的目的是什么？

  2. 您的主源存储库在哪里？

  3. 开发工作在哪里完成？

  4. 测试在哪里进行？

原文

I am setting up some servers for website development. I want it to be organized in a fairly standard way. How do you organize your servers for development of relatively small websites, each with a little bit of unique code?

Some details I am concerned about include (but not limited to):

  1. What distinct servers exist with respect to the development process? What is their purpose?

  2. Where is your master source repository?

  3. Where is development work done?

  4. Where is testing done?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（3）

羅雙樹2024-08-12 08:36:55

在开发过程中存在哪些不同的服务器？它们的目的是什么？

  • SCM 服务器 例如 SVN、Git、CVS - 通常是中央源存储库
    仅限内部访问。
  • CI 服务器 例如 CruiseControl、Hudson - 持续集成
    用于自动化构建/测试的服务器。
  • 文件服务器 例如 Samba、共享 Windows 目录 - 用于存储构建的
    工件，在之间共享下载
    开发团队
  • 测试/登台/生产服务器 - 按照相同规格构建的机器
    用于运行实际的硬件/软件
    应用。

您的主源存储库在哪里？

通常仅限内部访问，可以与其他目的（例如 CI）共享此计算机。

开发工作在哪里完成？

在每个开发人员的本地计算机上最好，然后通过 SCM 和 CI 集成更改。

测试在哪里进行？

通常在预留用于测试的服务器上。通常有一组环境，并且构建在通过测试时会在每个阶段进行升级：

  • 测试机 - 用于检查构建，通常反映开发人员机器的设置。
  • 登台机 - 对于通过基本测试的构建 - 该服务器将更像是实时生产系统的镜像。
  • 预上线 - 一个可选服务器，在服务器完全上线之前将提供给业务用户进行测试。
  • 实时/生产 - 当测试人员和业务部门接受构建后，构建就会升级到此服务器。

What distinct servers exist with respect to the development process? What is their purpose?

  • SCM Server e.g. SVN, Git, CVS - central source repository, usually
    internal access only.
  • CI Server(s) e.g. CruiseControl, Hudson - Continuous Integration
    server for automated builds/testing.
  • FileServer e.g. Samba, Shared Windows directory - for storing built
    artifacts, sharing downloads between
    the development team
  • Test/Staging/Production servers - machines built to the same spec of
    hard/software for running your actual
    application.

Where is your master source repository?

Usually internal access only, can share this machine with another purpose e.g. CI.

Where is development work done?

On each developers local machine is best, then integrate changes via SCM and CI.

Where is testing done?

Usually on a server set aside for testing. Normally there is a set of environments and builds are promoted through each stage as they pass testing:

  • Test machine - for checking out builds, usually mirrors the setup of a devlopers machine.
  • Staging machine - for builds that pass the basic tests - this server will be more of a mirror of the live production system.
  • Pre-live - An optional server which will be given to business users to test before the server goes fully live.
  • Live/Production - builds are promoted to this server when they have been accepted by the testers and the business.
回复 原文
无言温柔2024-08-12 08:36:55

1) 在开发过程中存在哪些不同的服务器？
他们的目的是什么？

根据我的经验，唯一重要的概念/想法是所有环境（服务器 => 开发、登台、生产）在操作系统、Web 服务器方面即使不完全相同，也应该相似版本、服务包、补丁、修补程序等。现在，拥有至少 3 个（或更多）不同环境可能可行，也可能不可行，但根据我的经验，这往往是常态。就硬件而言，只要它们非常相似或相同，就不会造成任何问题。

2) 你的主源在哪里
存储库？

与互联网隔离且戒备森严。许多防火墙规则可以保护它免受不良尝试的访问。只有内部开发人员才能访问存储库。

3）开发工作在哪里完成？

在较大的项目或组织中，开发往往在程序员的计算机上本地完成，或者借助源存储库（SVN、CVS、VSS 等）在本地完成工作的副本。

4）测试在哪里进行？

有些人在“开发”环境中进行测试，其他人在“分阶段”中进行测试，这对我来说更有意义。选择两者之一并坚持下去。就我个人而言，我认为如果开发人员对开发进行更改，则可以进行测试以避免版本更改。

您如何组织您的服务器
发展规模相对较小
网站，每个网站都有一点点
独特的代码？

基本上，网上商店将其环境组织为：开发=>开发，登台=>阶段，生产=>产品。开发人员在自己的计算机上本地工作，一旦完成添加/更改，他们就会将更改提交到源存储库。某些商店会执行称为 CI（持续集成）的操作，因此在开发人员每次提交后，CI 服务器都会自动重建到站点。这可以帮助开发人员/测试人员查看开发人员更改是否有任何问题。

通常，这些更改会发布到他们的开发环境中，供所有开发人员使用。当开发人员到达某个里程碑/检查点并想要开始测试时，他们将其网站的版本“升级”到暂存环境，以便测试人员进行锤炼，同时开发人员可以继续在开发中工作。

一旦每个人都对暂存中的一切感到满意，他们就会将暂存中的版本升级为产品。更改应该仅以一种方式流动：开发->阶段->产品。如果您想对生产进行更改，请从开发开始，然后在登台进行测试，然后升级到生产。这是一种痛苦，但它可以保持事情的一致性并防止许多令人头痛的事情。您会惊讶地发现，有多少公司只是在生产中进行了更改，几个月/几年后，他们在同步环境时遇到了问题，而只要遵循协议就可以为他们省去很多痛苦。

如果您指的是您的工作“小”，比如简单或不复杂，除了一些动态页面和一些数据库调用之外，我会说尝试使用 3 个环境，但您可能可以“摆脱”2 个环境（暂存）和生产）。你可以让你自己的电脑成为所谓的开发环境。

1) What distinct servers exist with respect to the development process?
What is their purpose?

In my experience, the only concept/idea that should matter is that all the environments (servers => development, staging, production) should be if not exactly alike, similar with regards to OS, web server versions, service packs, patches, hotfixes, etc. Now, it may or may not be feasible to have a minimum of 3 (or more) distinct environments, but this tends be the norm from my experience. In terms of hardware, as long as their very similar or identical it shouldn't pose any problems down the road.

2) Where is your master source
repository?

Isolated from internet access and heavily guarded. Lots of firewall rules to protect it from undesirable attempts at gaining access. Only developers in-house should be able to access the repository.

3) Where is development work done?

In larger projects or in organizations, development tends to be done locally on a programmer's computer or with the aid of source repositories (SVN,CVS,VSS,etc.) a copy of the work is done locally.

4) Where is testing done?

Some people test in their "development" environment, others do testing in "staging" which to me makes a little more sense. Pick one of the two and just stick with it. Personally, I think staging is the place to test to avoid version changes if developers are making changes to development.

How do you organize your servers for
development of relatively small
websites, each with a little bit of
unique code?

Basically, web shops organize their environments as: development=>dev, staging=>stage, production=>prod. Developers work locally on their own machine, and once their additions/changes are finished they commit the changes to the source repository. Certain shops do something called CI (continuous integration) so after every commit a developer makes, the CI server automatically rebuilds to the site. This helps developers/testers to see if anything broke from a developers changes.

Typically these changes are published to their dev environment for all developers to work with. When the developers get to a certain milestone/checkpoint and want to start testing they "promote" the version of their site to staging environment for testers to hammer away at while developers can continue to work in dev.

Once everyone is content with everything in staging, they promote the version in staging to prod. Changes should only flow one way: dev->stage->prod. If you want to make a change to production, start from dev then test in staging and then promote to production. It's a pain but it keeps things consistent and prevents from numerous headaches. You'd be amazed how many companies just make changes in production and months/years later they're having problems syncing environments when just following protocol would've saved them a lot of pain.

If you're referring to your work as "small" as in simple or not complex beyond some dynamic pages and some database calls, I'd say try to go for 3 environments but you could probably "get away with" 2 environments (staging and production). You could make your own computer the so-called development environment.

回复 原文
静谧2024-08-12 08:36:55

在工作中，我们偶尔会有两个人在同一个站点上工作，因此情况如下：

  • 每个站点都处于源代码控制（Microsoft Source Safe）中，并且我们大多数时间在自己的计算机上使用和测试本地副本。幸运的是，Visual Studio 2008 通过其内置的 Web 服务器使这一切变得简单。

  • 当我们想要对多个用户进行内部测试时，我们会部署到内部开发服务器。 （我们始终会在部署到生产之前执行此操作。）

  • 当我们希望一些外部聘请的顾问在进入生产之前检查站点时，我们可能会部署到我们的生产服务器，但使用特殊的主机头将其与实时站点分开，例如 staging.yourdomain.com（此步骤经常被跳过）。

  • 最后一步，我们部署到数据中心的生产服务器。

多年来我尝试过这种方法的各种变体。但这样做只需要2台物理服务器和开发人员的工作站。但它的结构足够好，对我们来说是一个可靠的过程。

At work we occasionally have two people working on the same site so it goes something like this:

  • Every site is in source control (Microsoft Source Safe) and we work with and test local copies on our own computers most of the time. Luckily Visual Studio 2008 makes this easy with its built-in web server.

  • When we want to test in-house with multiple users, we deploy to our in-house development server. (We will always do this before deploying to production.)

  • When we want some outside hired consultants to review the site before going to production we might deploy to our production server but with a special host header separating it from the live site, e.g. staging.yourdomain.com (This step is often skipped).

  • As a last step we deploy to the production server at the data center.

I've tried variations of this over the years. But doing it this way requires only 2 physical servers and the developer's workstation. And yet it's structured enough that it's been a dependable process for us.

回复 原文
~没有更多了~

关于作者

短叹

暂无简介

文章
评论
28 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

helenabai_sz

文章 0 评论 0

993438968

文章 0 评论 0

若能看破又如何

文章 0 评论 0

情未る

文章 0 评论 0

纪平伟

文章 0 评论 0

bobowiki

文章 0 评论 0

更多

友情链接

文江博客
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
原文