Customizations and Migrating fron Beta to Production

[jleaman]

I am trying to master the art of developing on a testing system and then applying changes to a beta system. This beta system, if approved, would have it's custom code checked into version control. These version controlled files would then be used to drop into the production site. In this way I would never need to use studio on the production site or go in and change production code by hand.

My assumptions were that I only need to revision the original module packages that I used when building custom modules as well as the ./custom/ directory for all other customizations. This assumption, sadly, is false. I believe there is db customizations I need within the fields_meta_data table as well as information located in the cache and data directories.

What files do I need to revision so I can confidently say "If my sugar application blew up I could get back to production with my revisioned files and a backup of the db."?

Another thought: If I am using revisioned files to drop into the production build and customizations are in the db would I need to revision the db and drop that into production? If so, I would need to be careful about what I take out of the db and revision because if I revision tables with user entered records I wouldn't be able to rely on that revision after it has been touched by end-users.

Any thoughts on the above or best practices for revision control with sugar and migration practices would be appreciated.

Thanks,
Jon

[salesagility]

There's a good article here (relating to 5.2 but the core principles are the same).

It doesn't address team development ... which is whole other problem!

[SugarDev.net]

Indeed, it's a good article.

Basically, it suggests that you keep your sugar under full source code control, instead of relying on Studio packages.

As you mention yourself, you have to have more then these packages to have a full backup of your installation. A full backup means the database (everything) + most of the code (you can skip some directories in cache, but not all of them). A functional backup (the installation without the data) would include all of the code and all of the database structure, but the contents of only a few tables (fields_meta_data, upgrades, config, user_preferences perhaps, etc.).

Your database does not need to be transferred between development and production. The only database-related stuff that Sugar cannot rebuild itself are these tables: fields_meta_data (custom fields definitions), upgrades (for installed modules), and custom fields in *_cstm tables. This last issue is a problem, because it requires you to re-do the creation of custom fields on both installations in exactly the same manner. When you do that, there is no need to synchronize fields_meta_data anymore, so you're left with 'upgrades' only.

[jleaman]

So after reading a bit I have come to the conclusion that you shouldn't ever use studio if you plan on tracking your code for the purpose of recovering from a catastrophe or using this code to migrate changes to production. The reason being, when you use Studio changes are made to the DB. This trumps the ./custom dir and causes some cyclical dependencies -- making it impossible to rely solely on code checked into version control for migration/backup purposes. Please correct me if I am wrong.

That said, historically at my company we have used studio to make customizations to the production system... Does anyone have a method for moving from a system that has been edited with Studio to a system that has customizations entirely dictated from the code?

Rant: Studio should dictate code -> code should dictate DB!

[JVWay]

Well, I do use Studio and what we do is diff the fields_meta_data and run insert or update statements on the db. Then run alters if I've added fields. It works very well. We also utilize a staging system in between dev and production so all changes are tested prior to upgrade. I've been doing this for 3 years and it's worked great.

I use Mercurial (hg) for source control as it's distributed and works very well with the number of files contained in Sugar.

[SugarDev.net]

I agree that customizations should either be code-based or datbabase-based, not both.

It may be interesting to create a little tool that can import/export fields_meta_data and can create missing _cstm fields accordingly.