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.
Version control workflow for semi-bespoke software
version control;development process;workflows;branching
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:Package Settings - This is where you can turn features on or off depending on how much money the client forks overUser 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).