Update Mechanism For Addons

Developers Dev talks
1

Hello there,



I dont know how you think about it but I would really love to see an update mechanism for addons. This doesnt need to be complex.



The following solution would suit that perfectly:


  1. Check the existing addon.xml files when a user opens the “Installable addons” tab page (if there is a newer version available than in the database - show “update” button)
  2. Now we need the posiblity to add two things in the addon.xml:



    a) Database content for this update:



    database/install.sql

    database/uninstall.sql

    database/update_051_07.sql





    B) Functions for the update





    fn_myaddon_install

    fn_myaddon_uninstall

    fn_myaddon_update





    Thats it. Because uninstalling+installing for getting new settings or database updates is a mess. And when you code the sql-uninstall propery all data is lost for the user. That should not be too hard to develop. Its just a small extension.



    And when you’re already doing this: please give us also a way to run a custom method if an admin enable/disable the addon. I know that there should be an hook for this (I think I saw it - not sure) - but I like clean architecture.



    What do you guys think about it?
2

Don't forget language variables, customer area templates, css changes, etc… User's may have modified templates or css files for an addon so have to have a way to determine how to merge changes. User's really don't appreciate it when you overwrite their changes.

3

Yes true thats a valid point - but from my persepective less important for this first step. Because they CAN use a merging tool (maybe we have to provide a video tutorial for it) for Templates and CSS changes. They anyway copy the new version to the folders so they can keep track for those changes. CS Cart can’t take care about this process (only when using online update - but that also needs an update feature like I mentioned → therefore this requirement for the possibility to have upgrades would be the first step in any direction).



PS language variables should be included in the “update” process definitly! Also Settings! ;-)! Otherwise it makes no sense. TZhe update is like a modified installation without really uninstall it first…



So the steps for an upgrade would be:

  • Just execute the SQL updates
  • Execute the custom update function
  • Reread all information from addon.xml (and translation files) and update database → existing values for the settings should be kept by the update process



    So its close to an installation without uninstall before.
4

I believe they are intending to augment the current “update” process by allowing addon developers to provide their own update notifications and then to utilize the same update mechanisms people are already familiar with.



No need to have anything in addon.xml. It can all be done via their current mechanism once they open it up and/or provide tools for working with it. Once an addon is installed, there's no further use for addon.xml other than for uninstall.

5

That would be a pitty :-( Because the work have to be done anyway (even if they use their update mechaism they have to check the currently installed version and update it accordingly). Should be low effort (just good architecture) to replace the addon and other files and then run the update mechanism.



And addon developers doesnt need to implement a special architecture just for this update process… they just have to upload their new zip packages (with low changes) and are done. I really would love to see a proper update for addons (which also works manually and user can merge before installation).

6

I too would like to see a “review, test, then publish” approach to any upgrade. I've asked for it since V2 but it has never been addressed.



Unfortunately, the range of skills in developers here makes the comment about “just good architecture” kind of moot.



We have automated our upgrade process and it dove-tails with our build process. When we release a new version, it is automatically distributed, prior instance backed up, installed and critical customer modified files updated without the user having to do anything. In most cases this is done in a matter of seconds. So when we find/fix a defect, all customers get the solution within a day or so of the change. Makes maintenance easier, customers are best served and we provide for things like “If prior version was X and current version is Z, do abc, else do def”. I.e. some releases may require a reload of a new template from the repository while others do not.

7

Pretty sad. You're speaking “review, test then publish” about a kind of multi-staging area (like I know for example from SAP systems - ERP and CRM)?



There you have an at least two or three tier system:

  1. Development
  2. Test
  3. Production



    Each change you do in develeopment have to be wrapped in a “Transport” which must be transfered to the next stage (and must be confirmed from someone - can be also yourself). If the test goes right you can transport it to production. A transport includes customizing (which is the same like settings), code and database changes. I also thought about how to implement it with cs cart. And the important part: you can't change anything in production - usually also test. So development, setting changes and automated updates / installing are only allowed on development or depending on the policy also for test. But never for production. Each fix must be transported from test first. No direct changes are possible (on settings, database or code). Maybe I'll find a solution next year - because I dont think CS Cart will spend time here and its also a question on how you install it on your machines - not just code in PHP-files.
8

You misunderstood what I was trying to say. Not that developers need the three steps, but rather the customers. Review an updates content, do an upgrade where it does not affect the running site. If all is well (or when issues are addressed) push the button to publish to production. The requirement to take a site offline to do an upgrade when you have no idea if it's a five minute or five day operation is crazy. The system soul support a built in sandbox.

9

Yes this is usually done by Customers :-) I got you right. Sorry maybe I was telling it wrong. Usually customers just need two tier (test and production). If they also develop maybe three tier. But the mechanism would be the same.



Edit: I mean “staging deployment”