ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

How to go about this

January 05, 2009 6:55am

Subscribe [4]
  • #1 / Jan 05, 2009 6:55am

    Tom Schlick

    386 posts

    im in the planning stages of a very big project that will hopefully turn into a profitable business. i will be providing customized cms service to a particular industry that is in need (sorry for not saying exactly what but id like to keep it quiet until its ready), and integrating a lot of services they already use separately into one application. i have a few questions that i need some help on figuring out solutions for though.

    1) What is the best way of managing multiple code bases through multiple servers? I will he hosting a bunch of sites all that will have the same code base (for the most part, some may have custom modules). So when i update code how can i “push” all of the code to X Y and Z paths at once? (The client wont have access to the code base for obvious security purposes)

    2) What is the best way of keeping track of database changes (table additions, columns, etc.) sort of like an svn for the layout of a db. This would be so when the dev team adds/removes features they would be able to quickly apply the changes to all databases.

    3) How can multiple domains share the same code base? such as if XYZ.com had a XYZ.com/store but they also wanted XYZstore.com to point to the store and do the same things that /store can. I think there would be hooks involved with this but i have no idea how to use them yet 😊

    Any advice / suggestions are greatly appreciated.

  • #2 / Jan 05, 2009 7:25am

    jalalski

    113 posts

    1) SVN (and other VCS) will allow you to ‘pull’ from the central code base. If you want to push, I think I would use rsync with an include file to clearly specify what files go where.

    2) Interesting question… I have no idea though 😊

    3) I may have misunderstood, but it sounds like the sort of thing you could do with Apache server aliases or with .htaccess redirects.

    HTH

  • #3 / Jan 05, 2009 10:34am

    Tom Schlick

    386 posts

    thanks jalalski,

    ya i planned on the svn part i just didnt know of a way to sync it to many servers at once

    i hope there is something out there that can track db changes… if not then i guess it will be just manual queries :(

    i was thinking that too but it might have some bad effects with the whole base_url thing in CI

  • #4 / Jan 06, 2009 8:55pm

    mikeyhell

    81 posts

    For your DB question, you might be able to use an ORM for your db schema.  I’m not sure how CI implements this with no shell app to build your db’s but w/ symfony you just load up the .yml and do a build-all-reload and your db is setup w/ data.  I’m actually glad you mentioned this, does anyone know of a brief tutorial w/ CI and something like doctrine.  I know Kohana has a built in ORM but what is everyone using w/ CI?

    Another option is incredibly complex and prone to breaks, but basically you use zamanda on your server to create incremental BU’s and setup a cron to rsync w/ your other servers, then setup a cron or sh app on that server to import the db.  This was a huge pain and not very streamlined though - wouldn’t recommend.

  • #5 / Jan 06, 2009 11:10pm

    Tom Schlick

    386 posts

    thats for the suggestion mikey ill look into ORM a bit more

  • #6 / Jan 07, 2009 11:15am

    m4rw3r

    647 posts

    I’ve made an ORM for CodeIgniter, and there are also a few more on this forum.

    I’m currently rewriting the manual for version 1.0, but it is fairly stable.
    Link in my sig.

  • #7 / Jan 08, 2009 2:16pm

    Tom Schlick

    386 posts

    ive decided (for now at least) i will deploy an upgrade script when a new version comes out that will update the db fields because ill have to have one anyways for the app itself. still dont have any idea of how to integrate multiple domains to one CI install.

    another thing. what is the best way for the app to call home? im thinking secured xml with a auth key in it. (the app will call home to check for updates, relay support requests that the help desk of the customer cant handle, and integrate data between sites). another way would be to add a db user but im thinking that could get complicated. thoughts?

    thanks in advance

  • #8 / Jan 08, 2009 5:51pm

    mikeyhell

    81 posts

    Are all the domains your wanting to have under 1 install on the same server?

  • #9 / Jan 09, 2009 3:44pm

    Tom Schlick

    386 posts

    ok here is how the domains would work.

    if XYZ.com had a XYZ.com/store but they also wanted XYZstore.com to point to the store and do the same things that /store can. I think there would be hooks involved with this but i have no idea how to use them yet

  • #10 / Jan 10, 2009 11:54pm

    t'mo

    44 posts

    For your DB schema problem one manual solution is to keep the script that builds the DB in source-control too. Somebody adds a column? That change goes into the DB creation script and is checked in. A table is split into two? That change goes int the DB creation script too (and checked in, of course).

    In fact, to make releases go smoother you can implement this approach in two scripts, a DB creation script and a “delta” script. When you release new code you run the delta to bring the DB in sync w/the code. E.g.,

    ALTER TABLE foo ADD COLUMN bar VARCHAR(100);

    Then, once the release is complete, just alter your DB creation script so in includes the new alterations. E.g., before:

    -- DB 1.0
    CREATE TABLE foo (
      id INT UNSIGNED AUTO INCREMENT PRIMARY KEY,
      mod_time TIMESTAMP);

    and after:

    —DB 1.1
    CREATE TABLE foo (
      id INT UNSIGNED AUTO INCREMENT PRIMARY KEY,
      bar VARCHAR(100),
      mod_time TIMESTAMP);</code></pre>

  • #11 / Jan 11, 2009 12:06am

    Tom Schlick

    386 posts

    For your DB schema problem one manual solution is to keep the script that builds the DB in source-control too. Somebody adds a column? That change goes into the DB creation script and is checked in. A table is split into two? That change goes int the DB creation script too (and checked in, of course).

    In fact, to make releases go smoother you can implement this approach in two scripts, a DB creation script and a “delta” script. When you release new code you run the delta to bring the DB in sync w/the code. E.g.,

    ALTER TABLE foo ADD COLUMN bar VARCHAR(100);

    Then, once the release is complete, just alter your DB creation script so in includes the new alterations. E.g., before:

    -- DB 1.0
    CREATE TABLE foo (
      id INT UNSIGNED AUTO INCREMENT PRIMARY KEY,
      mod_time TIMESTAMP);

    and after:

    —DB 1.1
    CREATE TABLE foo (
      id INT UNSIGNED AUTO INCREMENT PRIMARY KEY,
      bar VARCHAR(100),
      mod_time TIMESTAMP);</code></pre>


    ya it seems that manual scripts will be the best option for upgrading the database. i never thought of keeping that in the svn but it seems so obvious now. thanks!