10

In an ideal world, our development processes would be perfect, resulting in regular releases that were so thoroughly tested that it would never be necessary to "hotfix" a running application.

But, unfortunately, we live in the real world, and sometimes bugs slip past us and don't rear their ugly heads until we're already busy coding away at the next release. And the bug needs to be fixed Now. Not as a part of the next scheduled release. Not tonight when the traffic dies down. Now.

How do you deal with this need? It really can run counter to good design practices, like refactoring your code into nice, discrete class libraries.

Hand-editing markup and stored procedures on a production server can be a recipe for disaster, but it can also avert disaster.

What are some good strategies for application design and deployment techniques to find a balance between maintenance needs and good coding practices?

4

3 回答 3

2

[Even though we test a lot before we release, ] What we do is this:

Our SVN looks like this:

/repo/trunk/
/repo/tags/1.1
/repo/tags/1.2
/repo/tags/1.3

Now whenever we release, we create a tag which we eventually check out in production. Before we do production, we do staging which is [less servers but] pretty much the same as production.

Reasons to create a "tag" include that some of the settings of our app in production code are slightly different (e.g. no errors are emailed, but logged) from "trunk" anyway, so it makes sense to create the tag and commit those changes. And then checkout on the production cluster.

Now whenever we need to hotfix an issue, we fix it in tags/x first and then we svn update from the tag and are good. Sometimes we go through staging, with some issues (e.g. minor/trivial fixes like spelling) we by-pass staging.

The only thing to remember is to apply all patches from tags/x to trunk.

If you have more than one server, Capistrano is extremely helpful to run all those operations.

于 2008-09-27T15:42:32.437 回答
0

One strategy is to heavily use declarative-style external configuration files for the different components.

Examples of this:

In this way, you can often keep key components separated into discrete parts, hotfix a running application without recompile, and seamlessly use source control (particularly in comparison to stored procedures, which usually require manual effort to source control).

于 2008-09-27T15:51:03.150 回答
0

我们将代码分为框架代码和业务定制。业务定制类使用单独的类加载器加载，我们有工具可以将更改提交到正在运行的生产实例。每当我们需要对任何类进行更改时，我们都会对其进行更改并将其提交给正在运行的实例。正在运行的实例将拒绝旧的类加载器并使用新的类加载器实例再次加载类。这类似于 EJB 的 Jboss 热部署。

于 2008-09-27T16:18:13.567 回答