The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
If you really are doing a new production release every day, that's probably an indication that the development process itself has problems.
David Newton wrote:
If you really are doing a new production release every day, that's probably an indication that the development process itself has problems.
It seems like with most agile process that wouldn't really indicate a problem, though.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tristan Rouse wrote:Our system is semi-agile in that sense. We don't really make distinctions between development builds and production builds while the build is occurring, we just build and test until it we're happy with it and then deploy the builds that have been signed off on by their respective developers/testers to production. If our module happens to currently be of version label 4.0.113 (the label is incremented by cruise control on every build) then that's the name of the one that goes into production.
Additionally, this application's modules are deployed to many different server clusters in our production environment, and most modules have other modules as dependencies. Therefor all of the build artifacts would need to be deployed to the repository so that other modules can use them as input to their own builds.
Our source code versioning system maintains revision labels that correspond to build artifacts, so we are able to recreate any (*)AR we need if it is lost. What I'm trying to get away from however is maintaining the jars of module A as dependencies of modules B, C and Z in this versioning system.
Am I missing something important in snapshots? I'm not sure how they fit into the Maven picture and if they would be appropriate to use in any new build strategy for this system.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Nightly alpha's don't count in my definition of "production", though.
David Newton wrote:
Tim Holloway wrote:Nightly alpha's don't count in my definition of "production", though.
I think that's a limited view of what's possible with a good agile process. For example, see here for an example of continuous deployment taken to an extreme. If the processes are in place there's nothing "alpha" about it.
IMO there's no technical reason to wait an arbitrarily prescribed amount of time between feature releases.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Consider Paul's rocket mass heater. |