Automatic Add-on Builds Powered by Source Control
For the last two years I’ve been involved in the development and maintenance of large, feature rich add-ons for ExpressionEngine. These started out as primarily being internal projects for individual clients, but have since moved into my own work in the form of add-ons such as [ProForm][proform]. During this process of managing add-ons that have a rich set of features, I’ve run into a number of issues.
The add-ons that were developed internally at work were in use by multiple developers for multiple clients at the same time. Thus, each of these developers had competing and slightly incompatible goals and feature requests—features which all had to be done now, features that I had no reason (or ability) to say no to. This situation is the same that most add-on developers go through—we want to be able to say yes to all reasonable feature requests in a timely manner. Especially when first starting out as an add-on developer, one of the most important things you can do (aside from being generally helpful) is to say “yes” as often as possible.
This behavior can lead to a lot of stress. In my early experience with this kind of complexity, I was managing the same code base in multiple code bases then manually moving changes for each version between these separate projects. For most add-on developers the situation would be slightly different, but you can indeed end up with multiple versions of the same add-on. One for important client A, one for your own site, one for the default buyers.
The time scheduling issues aside (how exactly do you get two 100 hour features done in a week?) there was, at first, no way that I could manage the competing requests.
Implementing support for one critical feature would break an older feature, which had to be rewritten to use the new API provided by the first feature and so forth. At one point, things had gotten even worse with a separate developer implementing additions and changes directly to their own copy of an add-on, while I was receiving the same requests from other projects. So I’d then have to take the time to figure out how to merge those features back into the main version, while not taking other features along that those separate projects did not need.
Add-ons top of this that projects might still be running a very old version for weeks (the same is true for typical external customers), and then suddenly discover a bug that needs to be fixed in a very old version of the code. Is it easier to fix the old version, manually merge the changes into the current version, and move on? Or would it be better for them to upgrade to the latest version?
This whole situation was extremely unpleasant, and clearly unsustainable. It also wasn’t something I wanted to repeat with my own projects.