A new extension, "CDI" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Renamed the extension to "Continuous Database Integration", which is a bit more descriptive :)

This looks really interesting. Can it be used without a CI server?

What is the granularity of the SQL created? one file per section addition, one file per Field addition?

Well.. right now it is one file per SQL statement executed, but it might be adjusted in future versions because that could potentially create hundreds of files :)

And yes, you can do it without CI server. Copy the files in /manifest/cdi manually to the "Slave" instance and click the "CDI Update" link from the "System" menu.

Keep in mind that the extension must be installed and enabled on all copies of your Symphony instance. Also, it is very recommended to start off with a mutual base. So create a dump of your production data and copy it to the development environment. Clear the /manifest/cdi folder and then start making structural changes. Afterwards, you can copy the CDI scripts and it should update it automatically.

This sounds great! I'll definitely be giving this a try.

Thanks, that's good to know @remie. This will only touch the 'structure' of a site won't it, not the 'data'?

Indeed, it will only touch the structure. I've copied most of the lines to make the SQL statement selection from the Database Synchroniser extension, so it works identical. I only added the "memory" of already executed queries to prevent duplicate execution and me from having the flush the db_sync.sql file manually.

I'm really looking forward to trying this!

Looks very similar to me. I haven't looked through it yet, but I'm thinking we should probably merge them as they both do the same (or similar) things in almost identical ways. I did rip out all of the actual syncing code from DB Sync to keep things simple (and it didn't match our own deployment workflow), but this looks very cool so I'm interested to play with it soon :-)

Or to prevent duplication of code, if we don't fancy merging them, one extension could depend on the other (so SQL logging bugs need only be fixed in one extension). But that's only an idea!

I'm most interested to see how this would actually work with automated continuous integration itself, nightlies and so on.

@Nick: I would imagine that you will find a lot more similarities if you would actually start reading the code :)

Merging the two extensions might actually be a good idea. We can add preferences to control if it goes into a single file (including a "flush" command) or if it uses the execution log.

I've been playing around with the extension in my projects today and for now it actually works quite good. There is only one problem with the /manifest/config.php holding the extension preferences. If I commit this file to my code repository on the "Master", it will have the "is-slave" preference set to "No". However, on my other environments, I want this option to be "Yes".

For now I've been using my build script (Maven) to include different .htaccess and config.php files for my non-development environments. Perhaps there is a better solution for this, although I do imagine that I want the rest of my configuration (like database config) to be different in my environments as well.

Unfortunately, non of my current projects are public, so I can't give you access to a running environment to play around, but it is pretty much straightforward. The CI server:

  1. Does a checkout from my mercurial repository
  2. Runs the maven build
  3. Extracts the WAR artifact
  4. Uses rsync to synchronize the files on the webserver
  5. Uses curl to call the extension "update" REST interface

Et voila, the structure changes are implemented :)

wow 2 thumbs up ! This is really great !

Continuous Database Integration (CDI) updated to version 0.2.0 on 19th of July 2011

Nice extension, as said I'd love to see this integrated with the DB synchroniser extension.

remie, for your config file management issues, take a look at how buzzomatic approached it: (in the section titled 'The Manifest')

To summarise, you keep two (or more) copies of the manifest folder in your repo, and on each machine, symlink to whichever manifest folder you want to use (development, integration, production etc)

I've been doing it this way for a while now, and it works quite well. The only real issue I have is that if I add new extensions or config file options, I manually copy and paste the details between config files. Not a big deal and doesn't happen often, but thought I would mention it.

Yeah, i've thought of that approach, but because I already have a Maven build for running the YUI compressor (and some other tasks), it is just as easy to have the build generate the correct config file using property replacement.

The symlink solution works great if there is no build script involved!

In regard to the integration with the DB Synchroniser: I'll create an item on the roadmap that the CDI extension should also support the 'simple' way (a single file).

What would be the best approach to merge these two extensions?

I've integrated the DB_Sync functionality (and additionally added file upload and execution from the preferences screen).

@Nickdunn: can you please review my last commit and see if this implementation is good enough to merge the two extensions?

I've got a busy few days but hoping to look at this early next week. Deployment procedure is high up my list for some personal projects so this will be part of my investigating.

Continuous Database Integration (CDI) updated to version 0.3.0 on 22nd of July 2011

Just something to note, your repo should actually just include these files instead of entire extensions directory.

It's a bit of pseudo standard with Symphony extensions because the most common (documented) way to add extensions via github is with git submodule add git:// extensions/cdi which would checkout the files into the cdi directory.

Continuous Database Integration (CDI) updated to version 0.4.0 on 24th of July 2011

This is the last release before version 1.0.0. Only minor UI tweaks are required before it can be labelled a stable release.

UPDATE: I've added the issue list to Github: Feel free to pick up a task and contribute! :)

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details