Re: Create a sandbox -- nothing forgotten?

Christian,

If you are not changing the base roundup code but only changing your tracker you could create a test tracker by adding something like the following to the site_config.ini file:

[it]
dryrun = 0
repos = tracker/it
dest = /var/www/html/it

[it_test]
dryrun = 0
repos = tracker/it
dest = /var/www/html/it_test

and adding/changing this target in the Makefile:

install:
        ${BIN}/python scripts/install_from_repos.py site_config.ini ${NAME}

(In our case BIN is /usr/local/bin) To make a test tracker do this:

  make install NAME=it_test

Put in your changes and repeat the install until you have all of the changes working. When you have finished testing do this:

  make install NAME=it

If I have something like menu changes, I put them in a separate script and run roundup-admin pointing first to the test tracker, and when testing is completed run it again pointing to the production tracker. The script would look something like this:

#!/bin/bash
# issue 14693
#DB=nwhcom
DB=nwhcom_test
echo "$DB"

TRACKER_HOME="/var/www/html/"

/usr/local/bin/roundup-admin -i $TRACKER_HOME/$DB set test_issues5 name="Incorrect sample \
submitted (TIQ, SNV) (YIMP)"


We have several test trackers. What I do is point the person who requested the change to the test tracker to make sure the change is what they wanted.

Tom Ekberg
Senior Computer Specialist, Lab Medicine
University of Washington Medical Center
1959 NE Pacific St, MS 357110
Seattle WA 98195
work: (206) 598-8544
email: [email protected]

On Fri, 13 May 2016, Christian Wolf wrote:

> Date: Fri, 13 May 2016 14:48:40 +0200
> From: Christian Wolf <[email protected]>
> To: roundupusers <[email protected]>
> Subject: [Roundup-users] Create a sandbox -- nothing forgotten?
> 
> Hello,
>
> as I want to do some coding in my roundup tracker I want to avoid
> crashing the productive system. Thus I thought of setting up a sandbox
> (a copy of the productive system) and keeping track of the changes
> there. If all goes right I can apply the changes from the sandbox to the
> productive system.
>
> I just want to avoid crashing my productive system in the meantime while
> hacking in the sandbox.
>
> My setup is a direct piping of incoming mails using /etc/aliases and the
> backend is mysql storage.
> I thought of exporting the mysql database as backup and replacing the
> name of the database with a new one. Then I reimport the modified sql
> commands to generate a copy of the database with different name. I copy
> the tracker folder and in the config.ini I alter the rdbms->name to the
> sandbox database name.
> This should be it. I might add an alias to the mail server but this
> depends on the further setup.
>
> I just want to know if I forgot anything of if in the database there is
> any data that must be changed in order to avoid damage to the production
> system.
>
> Thanks a lot
> Christian Wolf
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Roundup-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/roundup-users
>



------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j