代码/Web 应用程序部署的最佳实践? [英] Best Practices for Code/Web Application Deployment?
问题描述
我很想听听有关如何最好地将代码从开发服务器移动到生产服务器的想法.
I would love to hear ideas on how to best move code from development server to production server.
一个陷阱列表，不要做这个列表会有帮助.
A list of gotcha's, don't do this list would be helpful.
任何有助于自动化步骤的工具.
Any tools to help automate the steps of.
根据这些文件列表备份现有代码
Make backups of existing code, given these list of files
记录这些文件从开发到生产的部署
Record the Deployment of these files from dev to production
在部署或应用程序以任何方式失败时允许更轻松地回滚...
Allow easier rollback if deployment or app fails in any way...
我从来没有在一家有部署过程的公司工作过，除了一个非常手动的从开发到生产的 ftp 文件.
I have never worked at a company that had a deployment process, other than a very manual, ftp files from dev to production.
你在你的公司、部门等做过什么?
What have you done in your companies, departments, etc?
谢谢...
是的，我是一个 Coldfusion 程序员，但文件就是文件，这应该是与语言无关的问题.
Yes, I am a coldfusion programmer, but files are files, and this should be language agnostic question.
推荐答案
好的，我会咬的.这个问题的技术方面，其他答案已经涵盖.但真正的问题是过程问题.真正的重点应该是确保有意义的软件开发生命周期 (SDLC) - 规划、开发、验证和部署.我将依次介绍每个.您想要的是每个阶段的可重复活动.
OK, I'll bite. There's the technology aspect of this problem, which other answers have already covered. But the real issue is a process problem. Where the real focus should be ensuring a meaningful software development life cycle (SDLC) - planning, development, validation, and deployment. I'll cover each in turn. What you want is a repeatable activity at each phase.
阐明和记录要交付的内容.通常门票或用户故事就足够了.有时您会做更多事情，例如客户签署的书面需求文档，这会被翻译成各种工件，例如 书面用例 - 最终你想要的是记录在电子系统中的东西，你可以将代码的更改与它相关联.这导致我...
Articulating and recording what's to be delivered. Often tickets or user stories are enough. Sometimes you do more, like a written requirements document, that a customer signs off on, that's translated into various artifacts such as written use cases - ultimately what you want though is something recorded in an electronic system where you can associate changes to code with it. Which leads me to...
还记得那个电子系统吗?好的.现在，当您对代码进行更改(您承诺进行源代码控制对吗?)时，您会将这些更改与该电子系统中的某些内容相关联——通常是票证.我喜欢 Trac，但也听说过有关 Atlassian 的套件.这为您提供了可追溯性.因此，您可以断言已完成什么以及如何完成.然后你可以使用这个系统和源代码管理来创建一个 build - 任何更改所需的所有位 - 以及内置源代码管理的 tag - 这是你的更改列表.更好的是，构建包含所有内容，以便它是可以轻松部署的独立实体.然后将构建交付给...
Remember that electronic system? Good. Now when you make changes to code (you're committing to source control right?) you associate those change with something in this electronic system - typically tickets. I like Trac, but have also heard good things about Atlassian's suite. This gives you traceability. So you can assert what's been done and how. Then you can use this system and source control to create a build - all the bits needed for whatever's changed - and tag that build in source control - that's your list of what's changed. Even better, have a build contain everything, so that it's standalone entity that can easily be deployed on it's own. The build is then delivered for...
也许是许多商店忽略的最重要的一步 - 后果自负.在生产过程中发现的缺陷比在流程早期发现时的修复成本要高得多.在许多商店中，验证通常是唯一发生这种情况的步骤 - 所以请确保您的商店这样做.
Perhaps the most important step that many shops ignore - at their own peril. Defects found in production are exponentially more expensive to fix then when they're discovered earlier in the process. And validation is often the only step where this occurs in many shops - so make sure yours does it.
这不应该由程序员来做！这就像狐狸看鸡舍一样.无论谁在做，都应该遵循某种计划.我们使用 测试链接.这意味着每个构建都以相同的方式进行验证，因此您可以识别 回归 错误.而且，此构建的部署方式应与您在生产中的部署方式相同.
This should not be done by the programmer! That's like the fox watching the hen house. And whoever is doing is should be following some sort of plan. We use Test Link. This means each build is validated the same way, so you can identify regression bugs. And, this build should be deployed in the same way as you would into production.
如果一切顺利(我们通常需要至少 3 次构建)，则构建已验证.这就是……
If all goes well (we usually need a minimum of 3 builds) the build is validated. And this goes to...
这应该不是事件，因为您正在按照与测试相同的步骤进行经过验证的构建.可能首先它会到达一个临时服务器，那里有一个自动复制过程，但关键是此时这不应该成为问题，因为您使用相同的过程进行了验证.
This should be a non-event, because you're taking a validated build following the same steps as you did in testing. Could be first it hits a staging server, where there's an automated copying process, but the point being is that is shouldn't be an issue at this point, because you validated with the same process.
就知道什么在哪里而言，您真正想要的是一种将更改组合在一起的合乎逻辑的方式.这就是 构建 的想法出现的地方.它确实是应该在 SDLC 中的步骤之间进行分隔的单元.如果你已经拥有了，那么理解给定系统状态的能力就变得微不足道了.
In terms of knowing what's where, what you really want is a logical way to group changes together. This is where the idea of a build comes in. It's really the unit that should segue between steps in the SDLC. If you already have that, then the ability to understand the state of a given system becomes trivial.
这篇关于代码/Web 应用程序部署的最佳实践?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
