Dev & Prod RT

So i am setting up 2 machines, one will be my Dev machine and the other
the production.

If i start out with both machines equal then make changes to the dev
machine. To bring the production one current all I’d need to do is rsync
the /opt/rt3 directory to the prod machine?

Basically I’m making sure that what isn’t in the DB is contained in
the /path/to/rt3 folder. I’m pretty sure, just wanted to make sure
before i commit to this setup :slight_smile:

–Ryan

Basically I’m making sure that what isn’t in the DB is contained in
the /path/to/rt3 folder. I’m pretty sure, just wanted to make sure
before i commit to this setup :slight_smile:

what exactly are you attempting to do? prototype some changes then
move them into production?

RT writes nothing to that directory. Only stuff you put or modify
there will be there. RT writes everything to the DB. The only non-
stock file that I have in that directory is the RT_SiteConfig.pm file.

smime.p7s (2.47 KB)

If i start out with both machines equal then make changes to the dev
machine. To bring the production one current all I’d need to do is
rsync
the /opt/rt3 directory to the prod machine?

Basically I’m making sure that what isn’t in the DB is contained in
the /path/to/rt3 folder. I’m pretty sure, just wanted to make sure
before i commit to this setup :slight_smile:

I think you’ve hit the nail on the head here, most of what makes RT is
within the Database. I’ve dumped out my DB and moved it from Dev to
Prod when I’ve done the initial setup. Doing that later once Prod has
been active is a little tricky, I’m sure some smart person has a way to
sync the Templates & Scrips, but I usually open 2 windows and cut and
paste once I’ve got a new setup working well on my Dev RT.

If you’re making changes to RT_SiteConfig.pm or adding customization in
/opt/rt3/local/ then rsync could be used. I suspect those changes
wouldn’t be that many. Give rsync -n a run and see what the differences
are.

If any gurus out there want to enlighten me to a solution of moving
custom fields from Dev to Prod without retyping, I’m listening. :slight_smile:

  • Scott

Even if you could bring over custom fields, you’d have to create them in
the exact same order on both machines because each one has a number that
is used internally to identify it.

Scott Golby wrote:

Well right now I am running 3.6.1 on prod and my new dev is 3.6.3 and
accessing the old database. I’m assuming this works because there are no
major changes. When I move the 3.6.3 to prod i’ll update the database.
My bigger concern is when i go to add things to the interface, or
generally muck around in RT :slight_smile:

I want to be able to put succusful changes to the dev or bring prod back
to dev if i hose something.

for larger updates I’m guessing I’d actually make a prod DB then mess
with it and when I am happy with replicating the process i’d do it on
prod, then make dev match prod and tweak there again.On Thu, 2007-01-18 at 15:24 -0500, Scott Golby wrote:

If i start out with both machines equal then make changes to the dev
machine. To bring the production one current all I’d need to do is
rsync
the /opt/rt3 directory to the prod machine?

Basically I’m making sure that what isn’t in the DB is contained in
the /path/to/rt3 folder. I’m pretty sure, just wanted to make sure
before i commit to this setup :slight_smile:

I think you’ve hit the nail on the head here, most of what makes RT is
within the Database. I’ve dumped out my DB and moved it from Dev to
Prod when I’ve done the initial setup. Doing that later once Prod has
been active is a little tricky, I’m sure some smart person has a way to
sync the Templates & Scrips, but I usually open 2 windows and cut and
paste once I’ve got a new setup working well on my Dev RT.

If you’re making changes to RT_SiteConfig.pm or adding customization in
/opt/rt3/local/ then rsync could be used. I suspect those changes
wouldn’t be that many. Give rsync -n a run and see what the differences
are.

If any gurus out there want to enlighten me to a solution of moving
custom fields from Dev to Prod without retyping, I’m listening. :slight_smile:

  • Scott

My bigger concern is when i go to add things to the interface, or
generally muck around in RT :slight_smile:

The Interface stuff tends to be editing files in /opt/rt3/local so your
rsync should work there.
http://wiki.bestpractical.com/index.cgi?CleanlyCustomizeRT

For the ‘general mucking around’ I’ve found to be in the Templates &
Custom Fields, which goes in the Database. You can do a lot of cool
stuff in the Templates using code and as the Queue Templates override
the Global Templates I’ve found this is where most of my changes have
gone.
http://wiki.bestpractical.com/index.cgi?CodeSnippets

  • Scott

Hi

My bigger concern is when i go to add things to the interface, or
generally muck around in RT :slight_smile:

The Interface stuff tends to be editing files in /opt/rt3/local so your
rsync should work there.
Request Tracker Wiki

I’ve been using plain old scp between dev and prod, mainly because
there’s usually other stuff in dev that isn’t ready for prod just yet.

We’re now looking at going to 3.6.x and I’m thinking about changing this
and using CVS - commit on dev, update on prod; and it would also give a
nice trail of how files change over time (there’s one file that’s had 3
edits for 3 separate tweaks, but 6 months down the line and I’m having
trouble figuring what’s doing what). Any thoughts?

Cheers
Toby

I’ve been using plain old scp between dev and prod, mainly because there’s
usually other stuff in dev that isn’t ready for prod just yet.

We’re now looking at going to 3.6.x and I’m thinking about changing this and
using CVS - commit on dev, update on prod; and it would also give a nice
trail of how files change over time (there’s one file that’s had 3 edits for
3 separate tweaks, but 6 months down the line and I’m having trouble figuring
what’s doing what). Any thoughts?

Well, of course you should use svk instead of cvs, but other than that,
yes, that sounds like a good idea.

I strongly recommend using some sort of version control. Our RT
installation is the combination of 8 separate projects stored within an
SVN repository:

  1. rt/bp: the best practical RT distribution + some RTx extensions.
  2. rt/cac/html: the local/html directory
  3. rt/cac/lib: the local/lib directory
  4. rt/conf/status: config directives for development level (Develmode)
  5. rt/conf/db: config directives for database connection
  6. rt/conf/base: remaining configuration directives
  7. rt/bin: some management scripts (mostly run from cron).
  8. rt/perl: the perl installation that rt uses

Then our milestones are a combination of specific releases of each
project. Being able to easily revert to a previous milestone has saved
our ass a couple times.

jbw

Toby Darling wrote: