Multiple Versions Of Application
-
Hello, CP, and good afternoon. I'm not sure if this is the correct forum but it seemed like the best fit. Please redirect if not. Anyhow, I've been thinking a lot about this lately. Where I work, we have various partners who we work with for software solutions. Many of them create custom builds of their existing software to fit our needs. How would one go about creating customized builds of software to fit specific needs without modifying the entire solution? Is this implemented via source control, duplicating the project or what?
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
-
Hello, CP, and good afternoon. I'm not sure if this is the correct forum but it seemed like the best fit. Please redirect if not. Anyhow, I've been thinking a lot about this lately. Where I work, we have various partners who we work with for software solutions. Many of them create custom builds of their existing software to fit our needs. How would one go about creating customized builds of software to fit specific needs without modifying the entire solution? Is this implemented via source control, duplicating the project or what?
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
This is the perfect place for this question, so don't worry about it. To answer your question, for custom builds for clients, we use source control to manage this. Basically, we have a branching strategy where these clients are branched off our main development trunk. Appropriate changes from the trunk can be merged down to those branches as appropriate. The process is a lot more involved than this, but that's the basic level (because we have branches off branches, to deal with test phases, etc, and release branches - it all sounds horrendously complicated, but our CI procedures make it a complete breeze).
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
Hello, CP, and good afternoon. I'm not sure if this is the correct forum but it seemed like the best fit. Please redirect if not. Anyhow, I've been thinking a lot about this lately. Where I work, we have various partners who we work with for software solutions. Many of them create custom builds of their existing software to fit our needs. How would one go about creating customized builds of software to fit specific needs without modifying the entire solution? Is this implemented via source control, duplicating the project or what?
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
Depends on what the needs are. Some possibilities exist with many variations within each. - Create abstraction layers. Customer specific code replaces the default implementation. - Run time meta data. The application functions differently based on data that drives the application. This can include but is not limited to run time scripting. - Distinct application layers. A customer choice replaces a default layer. - Customer overlays. Customer software is created which is part of a build step which either replaces source or binary sources with customer specific idioms. - Extract customer choices and push them back into the main code base.
-
Hello, CP, and good afternoon. I'm not sure if this is the correct forum but it seemed like the best fit. Please redirect if not. Anyhow, I've been thinking a lot about this lately. Where I work, we have various partners who we work with for software solutions. Many of them create custom builds of their existing software to fit our needs. How would one go about creating customized builds of software to fit specific needs without modifying the entire solution? Is this implemented via source control, duplicating the project or what?
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
Source control is by far the easiest way to do this. It gives several benefits, to name a few: Reverse Integration (fix a bug in one, move it everywhere) Single point of backup (Developers don't have all the code on their machine) Versioning Simple version differencing Many more. Once you start using something like TFS you'll never go back.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
-
This is the perfect place for this question, so don't worry about it. To answer your question, for custom builds for clients, we use source control to manage this. Basically, we have a branching strategy where these clients are branched off our main development trunk. Appropriate changes from the trunk can be merged down to those branches as appropriate. The process is a lot more involved than this, but that's the basic level (because we have branches off branches, to deal with test phases, etc, and release branches - it all sounds horrendously complicated, but our CI procedures make it a complete breeze).
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
I understand. It does indeed sound complicated but thinking enough about it, I can see how it really isn't so painful. Haha. Thank you all for the input! I use Git for source control, although I am a standalone developer, both independently at home and at work. I'm the only developer. But I've read about the many benefits of source control, even if you're a single developer. And I have seen truth to it all. Haha. But I'll look into branching more, I've seen the term in Git, just never took the time to learn. Thanks again!
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
-
Source control is by far the easiest way to do this. It gives several benefits, to name a few: Reverse Integration (fix a bug in one, move it everywhere) Single point of backup (Developers don't have all the code on their machine) Versioning Simple version differencing Many more. Once you start using something like TFS you'll never go back.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
Expert Coming wrote:
Source control is by far the easiest way to do this
That doesn't seem to have anything to do with the OP. The OP has a single product to which customizations must be done to support different customers. They are already aware of how to do that using completely different code bases (which is the only way in which source control can have an impact.) What they want is ideas on how to do that differently.
-
Expert Coming wrote:
Source control is by far the easiest way to do this
That doesn't seem to have anything to do with the OP. The OP has a single product to which customizations must be done to support different customers. They are already aware of how to do that using completely different code bases (which is the only way in which source control can have an impact.) What they want is ideas on how to do that differently.
The last sentence in the OP is what I was replying to. He asked if this is usually done in SCC, to which my response was that it is the easiest way. I did however fail to provide specifics which I should have done.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
-
Depends on what the needs are. Some possibilities exist with many variations within each. - Create abstraction layers. Customer specific code replaces the default implementation. - Run time meta data. The application functions differently based on data that drives the application. This can include but is not limited to run time scripting. - Distinct application layers. A customer choice replaces a default layer. - Customer overlays. Customer software is created which is part of a build step which either replaces source or binary sources with customer specific idioms. - Extract customer choices and push them back into the main code base.
A custom build is necessarily a different BUILD, so things like run-time metadata is out the window. :)
-
Depends on what the needs are. Some possibilities exist with many variations within each. - Create abstraction layers. Customer specific code replaces the default implementation. - Run time meta data. The application functions differently based on data that drives the application. This can include but is not limited to run time scripting. - Distinct application layers. A customer choice replaces a default layer. - Customer overlays. Customer software is created which is part of a build step which either replaces source or binary sources with customer specific idioms. - Extract customer choices and push them back into the main code base.
A custom BUILD doesn't have much to do with configurability (run-time metadata as you call it). All of this is really architecture considerations to have in mind if you want to make it easy to create and deploy custom builds. None of it really addresses how to create custom builds. That is all about managing the code, and the short answer is "branches".
It depends. It *always* depends.