5

I have a web app product (PHP, MySQL) for which I offer a bespoking service. That is, you can buy the main product, which is quite extensive, and then have it customised however you like. This might include new features, adjusting fundamentally how existing features work, disabling features, making changes which require a different database schema, etc.

I want to find a sensible way of managing a large number of different releases of the product in version control such that I can make changes to the core and pull changes out to the releases as required, and also make changes to a release independently. Sometimes I might want to pull a change from release back into the core.

My instinct was to use Git, and have the releases as branches. It is possible to pick specific commits to merge back into the trunk, so I think this could work.

However everywhere I have looked suggests that it is a bad idea to have permanently separate code in branches. The suggestion is to use a single codebase and have all the differences in features configurable, so that each release can behave separately. This sounds fine for software which is sold in multiple editions, which have different features enabled, but I think it would be a complete mess for my software.

I'm looking for a good development workflow for a setup like this, which may or may not be based on version control.

Improve this question
2
  • 4
    Did you consider organizing your "adaptations" as "plugins" (that is, define some rather fixed API or protocol)?
    – Basile Starynkevitch
    Commented Sep 9, 2014 at 16:16
  • That's a very good suggestion, and perhaps should be written up as an answer. The disadvantage of the plugin approach would be that it would require a lot of work to impose the structure to support it, whereas a version-control-based approach would effectively organise that structure for you, albeit with reduced clarity and flexibility.
    – gandaliter
    Commented Sep 9, 2014 at 16:30

3 Answers 3

Reset to default
4

Create one massive application with features being something you can turn on and off using configuration files or database settings. The display of the site, and the processing of user requests just becomes a matter of permissions management within the larger system. You'd have two basic levels of permissions:

  1. Package Settings - This is where you can turn features on or off depending on how much money the client forks over

  2. User Roles - This is subservient to Package Settings, and is where you define a "role" for a person (for example, an "Editor" vs a "Writer" vs an "Administrator"). "Writers" can create and edit content. "Editors" can publish it. "Administrators" can change settings.

Each feature should be its own "module". Every module could have one or more roles associated with it. For example, having a shopping cart module might not need an "Editor", but a "Product Manager" might be just the ticket.

Keeping this information in a database and creating a management system for these permissions would give you tons of flexibility for repackaging this software in the future. During the Great Recession, many companies saw their existing product offerings get rejected for cheaper alternatives. The companies that survived took the same features and repackaged them in different combinations to bring the cost down.

You should bear this in mind. If your market's price point suddenly shifts up or down, you should be able to easily repackage your software to take advantage of the price shift (or just survive and pay the bills until things improve).

Improve this answer
1
  • This is a terrible idea. Having worked with the "one massive application with features you can turn on or off..." many times throughout my career, I can say with certainty: this is almost never done right. The settings hive ends up with a meta type system, or a huge list of settings no one understands. The ability to turn on or off features without passing the system through a QA process leads to lots of production bugs due to a "bad setting". The UI to manage these settings becomes its own nightmare project. You are better off copy/pasting the entire codebase.
    – Chris McCall
    Commented Sep 11, 2014 at 19:57
3

The entire industry is looking for a good workflow for this. You have stumbled on a very common problem that most of systems design has been trying to solve for decades. How do you customize software without writing a whole thing from scratch each time?

Unfortunately, you've chosen php, which isn't very well-designed, so it won't have a lot of features to help you keep everything organized and abstracted out to the proper level of abstraction for each purpose. I will give you some general-purpose advice gathered from a couple of decades spent trying to solve this problem.

  1. Set firm boundaries. It's OK that your software isn't infinitely customizable. Infinitely customizable systems are also known as "development systems" which is what you yourself will be using to write your software: PHP, etc. Take it too far and you'll end up re-inventing the system you're using to write the system in the first place.

  2. Not everything has to be stored as a database setting. It's ok to offer customizations as files, like .css files or a set of module files in php dropped into a folder. You can also "hard code" your changes too.

  3. Don't use if-then statements with clientId or customerName to decide on what to do inside your software. Allow for file system directories or database values to key into the customer name, not control-of-flow statements.

  4. Most of the changes clients want will be in the UI, be it web pages or email messaging. Make those parts of the system easiest to change and count on making custom ones for each customer.

  5. Don't be afraid to white-label service offerings like Wordpress, MailChimp and the like. They have already made their systems multi-tenant, saving you time.

Good luck!

Improve this answer
0
2

Having branches for different version can work.

I think the main chore is keeping branch version up-to-date. So this approach suggest frequent merging/rebasing of changes in master and version branches to keep them up-to-date as required.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.