migrating to production
|
|
|
||||||||
|
|
||||||||
|
Tomasz Sterna wrote:
> Dnia 02-04-2007, pon o godzinie 11:23 -0500, Prabhat Jha napisa�?(a): >> I have tested hudson for couple of projects and it seems to fit most of >> our needs. Now, it's time to think about moving it to production >> environment. I am posting this thread so that I can gain from experience >> of others. I am mostly concerned about security. > > I personally find it easiest to put Apache HTTPd in front of mod_jk > connected Apache Tomcat workers. > This way I have TOTAL control over the webapp. > Enabling security with <Location > and <LocationMatch > directives is > trivial. :-) there seems to be no site that distributing the binary anymore. I'm just wondering if you'd be interested in documenting mod_jk setup somewhere? I'm sure other people will find it useful. -- Kohsuke Kawaguchi Sun Microsystems [hidden email] |
||||||||
smime.p7s (4K)
|
|
||||||||
|
|
Sergio Fernandes wrote:
> I'm also deploying Hudson in production in a few days, and what most > concerns me is the large number of "production" releases. > I know that this means that problems are quickly resolved, but it also > means that new problems can suddenly appear. OK. This is an interesting feedback for me. You probably won't have to keep up with every new release. You'll only need to upgrade when you want a specific new feature or bug fix. So I'm curious why frequent releases are hurting you. -- Kohsuke Kawaguchi Sun Microsystems [hidden email] |
||||||||
|
|
|
||||||||
|
|
Sergio Fernandes wrote:
> While in production, with a large number of developers and the QA tean > depending on it, we can have a huge impact if something goes wrong. So > it's important to be confident that we're taking the right release. > > Migration is always a risk and it's important to plan it in advance. > It's easier to plan an upgrade when you have releases in a regular time > base. > > There's no method to bug fix previous releases without the risk of > bringing new bugs, if all releases have new features. > > What I suggest is to categorize and promote Hudson releases, based on > stability and a fixed set of features. > Other possibility is to keep one branch for production, that only > receives bug fixes (stabilization branch), while trunk receives the new > stuff. limitation. Testing an web application automatically still remains very difficult. So aside from a few sporadic tests that test the logic inside Hudson, the main QA effort is done by my deploying release candidates to my production system and have my colleagues use it. So any approach that requires two branches is very difficult, because only one of them can be tested. It's also difficult to have prolonged "no new feature" period, because I consider a quick turn around time for RFEs to be one of the assets of Hudson. So the only remaining approach is to always try to keep the quality of code at a relatively high level, by constantly deploying new features into production. Perhaps an possible approach is to annotate changelog so that you can see what are new features and what are bug fixes, or how many lines are changing between releases (assuming they can be auto-generated.) That might give you some hint as to which build is a bug-fix only build and which is not. Similarly, maybe we can list how many bugs were filed against that release. That can be also auto-generated, and you can use that to determine which build to use. Maybe this is where the commercial support is really useful. A service that lets you know the good release to start with, and perhaps even maintain a branch just for you, and backport some fixes if necessary. That's worth some money, isn't it ;-) Anyway, in practice, at this point I think most of Hudson (except the alpha m2 support) is fairly stable. I don't recall any serious regression at all. -- Kohsuke Kawaguchi Sun Microsystems [hidden email] |
||||||||
|
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
