Web 开发设置
我正在建立一个完整的网络开发环境。 目前，有两名开发人员，一名致力于后端编程（C#、.NET），另一名致力于前端开发（HTML、CSS、XSLT）。
每个都安装了 MS Visual Studio 2008 并通过 Visual Source Safe 2005 共享源代码。它们都签出文件并在本地进行开发。
我已经设置了一个测试服务器，其中计划合并和测试的代码最终应该结束，并且该服务器应该始终是“正确”的版本。
3 个安装均共享相同的数据库。
我认为这个设置应该稍微扩展一下，因为我正在为更多的开发人员做准备，但是我们在文件同步和快速更改的轻松访问方面存在很多问题。 通常我们需要快速更改一些布局和设计，最终手动将文件复制到测试服务器（我不希望网络服务器上有任何 .NET/C# 代码文件），并且站点会失败:-(
我们使用标准 CMS 来构建我们所有的前端工作，如果将其包含在源代码安全中，它确实会减慢速度。
我希望我们所有的前端工作与后端代码完全分开，这样很容易进行更改。
例如，我们想对设计进行一些更改并将其快速部署到我们的生产环境中，而不考虑
我遗漏的任何内容，或者设置网络的最佳实践是什么。 Thomas
期待一些帮助/经验:-)
/
I am in the process of setting up a complete web-development environment.
For now, there are two developers, one dedicated to backend programming (C#, .NET) and one dedicated to frontend development (HTML, CSS, XSLT).
Each have an installation of MS Visual Studio 2008 and shared source via Visual Source Safe 2005. They both checkout files and develop locally.
I have setup a test-server where it is the plan that the merged, and tested, code should finally end up, and that server should allways be the "correct" version.
Each of the 3 installations share the same databases.
I think this setup should scale a bit, as I'm preparing for more developers, but we have quite a lot of problems with file syncing and easy access for quick changes.
Often we need to change some layout and designs pretty quickly and end up copying files out to the testserver manually (I don't want any .NET/C# code-files on the webserver), and the site fails :-(
We use a standard CMS to build all of our frontend work, and it really slows things down if this is included in the source-safe.
I would like all of our frontend work to be kept completely separated from our backend code so It's easy to make changes.
Eg. we would like to make a few changes in the design and deploy it quickly to our production environment, without thinking about the .NET code.
Are there anyting I'm missing, or what is the best practice for setting up an web-development environment?
Looking forward for some help/experiance :-)
/Thomas
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能应该考虑一个功能更强大的版本控制系统。 SVN 拥有强大的工具支持（包括 AnkhSVN 和 VisualSVN（用于 VS2008 集成），以及像 Mercurial、Git 或 Bazaar 这样的分布式版本控制系统将为您提供更多选择和更多基本工具支持的价格。
您可能需要简单的分支，并且如果您可以轻松地将它们部署到生产环境（即运行“svn up”），那么使用版本控制系统管理相关资源就会变得更加容易。
You should probably look into a more-capable version control system. SVN has great tool support (including AnkhSVN and VisualSVN for VS2008 integration), and distributed version control systems like Mercurial, Git, or Bazaar will give you even more options and the price of much more basic tool support.
You may need easy branching, and managing the relevant resources using the version control system is made much easier if you can deploy them easily to production (i.e. run "svn up").
我无法帮助您提供有关如何处理 CMS 内容的信息，但我已经设置或使用了几个构建服务器。
我在很多项目中使用过 Visual Source Safe，在一些项目中使用过 Team Foundation Server，所以如果可以的话，我会远离它。
我们最近的构建服务器由 Nant 脚本组成，这些脚本从 Subversion 存储库中检查源代码。 构建本身是由 MSBuild 完成的。 然后，构建的结果将被复制到阶段和生产环境。
应该有一种简单的方法将数据库更改从开发转移到阶段和生产。 我们有一个工具（http://www.codeplex.com/ScriptDB）可以编写开发脚本数据库。 结果被签入 Subversion。 很容易在 Subversion 日志中看到发生了什么变化。
I can not help you with information about how to handle CMS content, but I have setup or used a couple of buildservers.
Having worked with Visual Source Safe in a lot of projects and Team Foundation Server in some, I stay away from it if I can.
Our recent buildserver consists of Nant scripts that check out the source from a Subversion-repository. The build itself is done by MSBuild. The result of the build is then xcopied to stage and production.
There should be an easy way to transfer database changes from development to stage and production. We have a tool (http://www.codeplex.com/ScriptDB) that scripts the dev-Database. The result is checked into Subversion. Its easy to see what changed in the log of Subversion.
这似乎是一个糟糕的决定。 如果 dev1、dev2 和 test 都使用相同的数据库，那么 dev1 如何在不干扰 dev2 和 test 的情况下尝试更改模式（假设尚未签入用于使用实验模式的代码）。
此外，数据库会成为单点故障，因此如果有人意外删除/截断了关键表，那么所有工作都会停止。
理想情况下，每个环境都应该有自己的数据库。 我想如果您使用像 Oracle 这样的非自由数据库，那么您可能无法为每个环境提供自己的服务器，但至少每个环境应该有自己的架构。
This seems like a poor decision. If dev1, dev2 and test are all using the same database, then how can dev1 experiment with changing the schema without interfering with dev2 and test (assuming the code for working with the experimental schema is not checked in yet).
Also, the DB becomes a single point of failure, so if somebody accidentally deletes/truncates a crucial table, then all work grinds to a halt.
Ideally, each environment should have it's own DB. I guess if you're using a non-free DB like Oracle, then you may not be able to afford to give each environment it's own server, but at least each environment should have it's own schema.