myDBR Forums » Extensions

Deploy once on Test, automatically make the change to Production after all tests

(5 posts) (4 voices)

  1. SongezoM, Member

    Hi,

    Whenever I use myDBR on my Test environment to create reports (queries, inputs, etc.), I always have to do the same thing on the Production environment when my report is done.

    Does myDBR have a 'deploy once' function I can use? Where I can just deploy all my relevant changes and additions from one environment to the export.

    Thanks a lot in advance.
    Songezo

  2. myDBR Team, Key Master

    Songezo,
    the answer depends a bit how your test environment and production environment are set up, so there is no really one answer or one way to do things.

    If the environments are identical, you can just copy the test environment's database to the production environment. If there are differences between the test and the production environment (user privileges, database names etc), you do have to move the relevant parts over to the production server more or less manually.

    This is part that is in the roadmap to be improved.

    --
    myDBR Team

  3. SongezoM, Member

    Ok. Thanks a lot.

    Looking forward to that improvement.

  4. Chris, Member

    What might be useful is if the mydbr_sync tool also extracted relevant config from related tables, and then also if it were able to import/reinstate this config into the database.

    Having the sp_ content in version control is useful as far as tracking diffs, etc., but it doesn't help with deployment or escalation from dev to test to staging to live.

    So another function of mydbr_sync should be to import an entire config bundle, being report defn's, sp's, and user/group/folder details -- that would really make it a 'sync' tool instead of just an extract tool as it currently functions. It would skip license and some of the other server-specific tables.

    FYI we accomodate hard config differences in the config files by symlinking each file to a config directory higher in the folder structure. The entire mydbr structure then gets put into version control (only the symlinks are stored, not the actual content of the config files which are held in different repositories).

    After development changes are made, we commit to version control and push to the test/staging/live servers. This is where having everything wrapped up in a config bundle (described above) would be ideal.

    Currently we have to extract the sql and sync it into the database manually every time we deploy, so the usefulness of mydbr to us is always going to be measured against the pain of it not fitting into a typical deployment process. That is the challenge presented because mydbr stores some information in config files, and some in the database (like the license hash, which should probably be in a file).

    Overall, however, a very useful tool! These improvements would be ideal.

  5. situ, Member

    I would love to see a way where a report or parts of a report could be selectively pushed from test to live servers.

    I view a report being made up of the following components

  6. The procedure itself
    The configuration around the report (parameters, descriptive text, etc.
    Access control to report

    7. I know this list is not conclusive but it is a good start.

    Being able to selectively push these items to other servers would be a great step forward. It is a simplistic approach and it does not cover issues around css files, parameter definitions etc. but it is a start. On a day to day basis parameter definitions and css files don't change often.


Reply

You must log in to post.