Re: Buildmanagement-Strategy
Nayan Hajratwala wrote: On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote: Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( Ahh -- the infamous internal processes. Perhaps you might find some help with that part of it over on the Scrum Development list http://groups.yahoo.com/group/scrumdevelopment/ :-) I think these processes are just the smaller part of the problem. The big one is the integration with the SCM, I think. Maven is a great tool to fullfill the first requirement, but the SCM is another important tool. And this is, what I'm worried about. :-) Stefan -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Buildmanagement-Strategy
I can't help but feel that you have completely obfuscated a relatively basic need. It's like you have the right tools but the wrong implementation. Why doesn't storing your artifacts in Nexus also along with Maven POMs to specify the dependencies for each project work for you? Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -Original Message- From: Stefan Schulze [mailto:algr...@gmx.de] Sent: Thursday, September 16, 2010 10:49 AM To: users@maven.apache.org Subject: Buildmanagement-Strategy Hi, My problem is not really only about Maven, but more about a general buildmanagement-strategy using Maven. I didn't found a mailinglist or newsgroup dedicated for general buildmanagement-topics, so try to post my issue in this list. I'm quite new to buildmanagement and have to think about a concept to support the evolutionary architecture (or better evolutionary development of the architecture) we want to employ in the future of our product. After hours and days of considering and contemplating we found two possible solutions. Because both has serious drawbacks, I hope that anybody of you already knows this scenario/requirements (I think it's not too unusual) or has any suggestions to improve our solutions. The requirements: 1) It is neccessary to support different modules (WARs) depending on the same module (JAR) in different versions: For example, first we developed a module booking in version 1. Some common stuff is implemented in core (version 1, too), where booking-1 depends on. Some time after release our customer wants to have an reporting-module, so wie develop reporting-1 and implement some improvements to core (because during the last project and in the meantime we saw, that there some decisions weren't ideal). So reporting-1 depends on core-2. We do not want to upgrade booking-1 to use core-2, because in this case, booking would have to pass QA again (and the customer wouldn't pay this - there is no new feature). 2) It is neccessary, that it's possible to fix booking-1 or even core-1 (a bug in booking-1 is in core-1, in truth), although core-2 is the current version of core and booking-1 wouldn't even compile against core-2. The infrastructure: 1) We use Synergy/CM for version-control. For this case it's similar to Subversion with release-branch strategy. In opposite to Subversion, cheap and/or history-preserving copies are not supported. 2) We use Maven2 with an own Nexus-repository. Currently we use Maven and Nexus just to serve third-party-libs and to give the developers the possibility not to have to checkout the full source, but only these parts, they work with. So the repository isn't really part of releasing a new version of our system - we not even create a Release-version of our snapshots. The (possible) solutions: 1) In each module are additional directories for the different versions. Each version-directory contains quite the same code (differing only in the changes made between the versions): core- |-1-src-... |-2-src-... ... This doesn't feel rights. It's somehow ugly, we copy code and we have to merge bugfixes manually from one version to all others. But it's a quite simple solution to solve both requirements. 2) Each release-branch contains only the current version of code. The other versions are taken from the Maven-repository (in this case we have to use release-version and all the stuff). If a bugfix is core-1 is neccessary, a developer check-out the release-branch 1, implement the bugfix, start the build and calls a build- or release-manager to deploy the release-version to the repository. If it's time to go live with a new version, an appropriate assembly is built, which contains in parts of fresh compiled code and in parts of artifacts out of the the Maven-repository. At the detail, this is a quite complex approach. I don't really like, that we don't have a release-branch containing the full production-code - instead we would release a mixture of different release-branches. If any of you has some experience with similar requirements, has an idea for a different solution or an suggestion to improve the one or the other solution, I would really appreciate your ideas and comments. Thanks for reading all of this quite long mail. :-) Stefan -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is
Re: Buildmanagement-Strategy
On 16/09/2010 10:48 AM, Stefan Schulze wrote: Hi, My problem is not really only about Maven, but more about a general buildmanagement-strategy using Maven. I didn't found a mailinglist or newsgroup dedicated for general buildmanagement-topics, so try to post my issue in this list. I'm quite new to buildmanagement and have to think about a concept to support the evolutionary architecture (or better evolutionary development of the architecture) we want to employ in the future of our product. After hours and days of considering and contemplating we found two possible solutions. Because both has serious drawbacks, I hope that anybody of you already knows this scenario/requirements (I think it's not too unusual) or has any suggestions to improve our solutions. The requirements: 1) It is neccessary to support different modules (WARs) depending on the same module (JAR) in different versions: For example, first we developed a module booking in version 1. Some common stuff is implemented in core (version 1, too), where booking-1 depends on. Some time after release our customer wants to have an reporting-module, so wie develop reporting-1 and implement some improvements to core (because during the last project and in the meantime we saw, that there some decisions weren't ideal). So reporting-1 depends on core-2. We do not want to upgrade booking-1 to use core-2, because in this case, booking would have to pass QA again (and the customer wouldn't pay this - there is no new feature). This is a common problem and when you quote the cost of reporting-1, you need to include the cost of releasing booking-1 with the new core library. You can reduce the cost by breaking core onto multiple smaller libraries that are less susceptible to change. With small changes to large systems, the cost of the release of a new system can be larger than the programming and testing of the actual change. 2) It is neccessary, that it's possible to fix booking-1 or even core-1 (a bug in booking-1 is in core-1, in truth), although core-2 is the current version of core and booking-1 wouldn't even compile against core-2. The infrastructure: 1) We use Synergy/CM for version-control. For this case it's similar to Subversion with release-branch strategy. In opposite to Subversion, cheap and/or history-preserving copies are not supported. 2) We use Maven2 with an own Nexus-repository. Currently we use Maven and Nexus just to serve third-party-libs and to give the developers the possibility not to have to checkout the full source, but only these parts, they work with. So the repository isn't really part of releasing a new version of our system - we not even create a Release-version of our snapshots. The (possible) solutions: 1) In each module are additional directories for the different versions. Each version-directory contains quite the same code (differing only in the changes made between the versions): core- |-1-src-... |-2-src-... ... This doesn't feel rights. It's somehow ugly, we copy code and we have to merge bugfixes manually from one version to all others. But it's a quite simple solution to solve both requirements. 2) Each release-branch contains only the current version of code. The other versions are taken from the Maven-repository (in this case we have to use release-version and all the stuff). If a bugfix is core-1 is neccessary, a developer check-out the release-branch 1, implement the bugfix, start the build and calls a build- or release-manager to deploy the release-version to the repository. If it's time to go live with a new version, an appropriate assembly is built, which contains in parts of fresh compiled code and in parts of artifacts out of the the Maven-repository. At the detail, this is a quite complex approach. I don't really like, that we don't have a release-branch containing the full production-code - instead we would release a mixture of different release-branches. If any of you has some experience with similar requirements, has an idea for a different solution or an suggestion to improve the one or the other solution, I would really appreciate your ideas and comments. You create releases that you store in Nexus (or some other repository). In your SCM, you store your software with properly named branches so that you can patch and rebuild anything that you have released. Thanks for reading all of this quite long mail. :-) Stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Buildmanagement-Strategy
On Sep 16, 2010, at 10:48 AM, Stefan Schulze wrote: The requirements: 1) It is neccessary to support different modules (WARs) depending on the same module (JAR) in different versions: That's good. Maven excels at that! For example, first we developed a module booking in version 1. Some common stuff is implemented in core (version 1, too), where booking-1 depends on. Ok, so both of these should be *released* versions such that you can refer to them in poms as: groupIdcom.yourcompany.project/groupId artifactIdbooking/artifactId version1.0/version groupIdcom.yourcompany.project/groupId artifactIdcore/artifactId version1.0/version the pom for booking:1.0 would depend on core:1.0 Some time after release our customer wants to have an reporting-module, so we develop reporting-1 and implement some improvements to core (because during the last project and in the meantime we saw, that there some decisions weren't ideal). So reporting-1 depends on core-2. so you now release a new version of core, core:2.0. Both 1.0 2.0 should have been deployed and should exist in your nexus repository. booking:1.0 continues to depend on core:1.0 reporting:1.0 depends on core:2.0 We do not want to upgrade booking-1 to use core-2, because in this case, booking would have to pass QA again (and the customer wouldn't pay this - there is no new feature). There is no need to upgrade it. 2) It is neccessary, that it's possible to fix booking-1 or even core-1 (a bug in booking-1 is in core-1, in truth), although core-2 is the current version of core and booking-1 wouldn't even compile against core-2. at this point the following versions have been released: core:1.0 core:2.0 booking:1.0 reporting:1.0 the current development snapshots would be: core:2.1-SNAPSHOT booking:1.1-SNAPSHOT (currently depends on core:1.0) reporting:1.1-SNAPSHOT (currently depends on core:2.0) If a bug is found in core:1.0 which is causing problems with booking, you have 2 options: Option 1: * update booking:1.1-SNAPSHOT to depend on core:2.1-SNAPSHOT. * Get everything compiling, etc with the new core * Fix the bug in core * release core:2.1 booking:1.1 Option 2: * branch core:1.0 to core:1.0.1-SNAPSHOT * fix the bug in core * release core:1.0.1 booking 1.1 The infrastructure: 1) We use Synergy/CM for version-control. For this case it's similar to Subversion with release-branch strategy. In opposite to Subversion, cheap and/or history-preserving copies are not supported. Never used Synergy, so i don't have any comments on it. 2) We use Maven2 with an own Nexus-repository. Currently we use Maven and Nexus just to serve third-party-libs and to give the developers the possibility not to have to checkout the full source, but only these parts, they work with. So the repository isn't really part of releasing a new version of our system - we not even create a Release-version of our snapshots. I think this is the big missing piece for you. In order to make your life easier, you need to develop on SNAPSHOTs and release releases to Nexus. The (possible) solutions: 1) In each module are additional directories for the different versions. Each version-directory contains quite the same code (differing only in the changes made between the versions): core- |-1-src-... |-2-src-... ... This doesn't feel rights. It's somehow ugly, we copy code and we have to merge bugfixes manually from one version to all others. But it's a quite simple solution to solve both requirements. Agreed that this is ugly and very error prone. 2) Each release-branch contains only the current version of code. The other versions are taken from the Maven-repository (in this case we have to use release-version and all the stuff). If a bugfix is core-1 is neccessary, a developer check-out the release-branch 1, implement the bugfix, start the build and calls a build- or release-manager to deploy the release-version to the repository. If it's time to go live with a new version, an appropriate assembly is built, which contains in parts of fresh compiled code and in parts of artifacts out of the the Maven-repository. At the detail, this is a quite complex approach. I don't really like, that we don't have a release-branch containing the full production-code - instead we would release a mixture of different release-branches. This would all be resolved by using the proper maven strategy. Hope this makes sense. Good luck! --- Nayan Hajratwala http://agileshrugged.com http://twitter.com/nhajratw 734.658.6032 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands,
Re: Buildmanagement-Strategy
Ron Wheeler wrote: This is a common problem and when you quote the cost of reporting-1, you need to include the cost of releasing booking-1 with the new core library. You can reduce the cost by breaking core onto multiple smaller libraries that are less susceptible to change. With small changes to large systems, the cost of the release of a new system can be larger than the programming and testing of the actual change. I'll talk with the architect tomorrow or on monday about this issue, but I think this isn't an option. The Java-parts of our system are growing since about ten years and contains ~100 modules. Our team is relatively new at this occupation, but it's obvious, that in the last ten years nobody had the heart to touch the existing infrastructure, because it would cost huge amounts of money (I'm not familiar to details, but we heard numbers with more than five digits) just for QA. This results in adding here something and there around the infrastructural components or duplication with slight changes - uncontrolled growing... As a consequence we want to establish a new architecture beside the old one and learning from these issues. So the evolutionary development of the architecture is somehow crucial. You create releases that you store in Nexus (or some other repository). In your SCM, you store your software with properly named branches so that you can patch and rebuild anything that you If I understand you right, this is the way we thought about. Is it correct, that your suggestion would lead to the same goal: we wouldn't have the One release-branch containing the complete currently released code-base? In our approach the current released code-base is splitted across multiple branches. Stefan -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Buildmanagement-Strategy
Nayan Hajratwala wrote: At the detail, this is a quite complex approach. I don't really like, that we don't have a release-branch containing the full production-code - instead we would release a mixture of different release-branches. This would all be resolved by using the proper maven strategy. I planned to do it similarly to the approach you described above. Thank you for the detailed description of the procedure. I've never worked with releasing in Maven before, so I didn't knew exactly what to do. I just had a rough conception. :) Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( For the beginning, I would be happy if I could integrate this maven strategy cleanly with the SCM. Stefan -- GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt freischalten! http://portal.gmx.net/de/go/maxdome - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Buildmanagement-Strategy
On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote: Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( Ahh -- the infamous internal processes. Perhaps you might find some help with that part of it over on the Scrum Development list http://groups.yahoo.com/group/scrumdevelopment/ :-) Good luck! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
