Best way to set up test RT instance?

Hello all,
I finally have RT sending out emails on the company’s server, so we’re
ready to move forward with testing things and making changes. To that end,
I’m wondering how everyone manages testing changes without affecting the
primary instance, then moving those changes into production?

My first thought is to have a second installation on the same server, maybe
in /etc/request-tracker4_test. The problems are how to deal with the other
places RT installs itself (I use the pre-packaged install) and how to tell
Debian to use that path in the first place.

My next option would be a whole different server, but doing that requires a
way to move items between the two. Besides, it seems more efficient,
somehow, to use one server rather than two.

Either way, I’ll have to merge the changes I find work on the test system
back to the real one. Is there a relatively simple way to do this, or do
people just manually repeat the work they did on the test system on the
live one? I’m not talking about source code changes, but, say, a new ticket
type or SLA. Thanks for any thoughts.

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

Hello all,
I finally have RT sending out emails on the company’s server, so we’re
ready to move forward with testing things and making changes. To that end,
I’m wondering how everyone manages testing changes without affecting the
primary instance, then moving those changes into production?

My first thought is to have a second installation on the same server, maybe
in /etc/request-tracker4_test. The problems are how to deal with the other
places RT installs itself (I use the pre-packaged install) and how to tell
Debian to use that path in the first place.

My next option would be a whole different server, but doing that requires a
way to move items between the two. Besides, it seems more efficient,
somehow, to use one server rather than two.

Either way, I’ll have to merge the changes I find work on the test system
back to the real one. Is there a relatively simple way to do this, or do
people just manually repeat the work they did on the test system on the
live one? I’m not talking about source code changes, but, say, a new ticket
type or SLA. Thanks for any thoughts.


Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

Hi Alex,

We use nginx to serve multiple independent installs from the same
server. The RT code + modifications is a pretty small footprint and
it allows us to have as full a test instance as we would care to
provide the resources.

Regards,
Ken

Do you run from source? If not, how did you direct RT to use alternative
paths during the install rather than using all the same ones and thus
failing to install or overriding existing files?

Were I to attempt a source install again, could I safely do so alongside
the current 4.2.8 instance on the server? Obviously I’d have to make a
different database, and couldn’t have both instances using the same email
addresses for sending/receiving, but what else would I have to consider?On Wed, Sep 21, 2016 at 2:09 PM, Kenneth Marshall ktm@rice.edu wrote:

On Wed, Sep 21, 2016 at 12:50:51PM -0400, Alex Hall wrote:

Hello all,
I finally have RT sending out emails on the company’s server, so we’re
ready to move forward with testing things and making changes. To that
end,
I’m wondering how everyone manages testing changes without affecting the
primary instance, then moving those changes into production?

My first thought is to have a second installation on the same server,
maybe
in /etc/request-tracker4_test. The problems are how to deal with the
other
places RT installs itself (I use the pre-packaged install) and how to
tell
Debian to use that path in the first place.

My next option would be a whole different server, but doing that
requires a
way to move items between the two. Besides, it seems more efficient,
somehow, to use one server rather than two.

Either way, I’ll have to merge the changes I find work on the test system
back to the real one. Is there a relatively simple way to do this, or do
people just manually repeat the work they did on the test system on the
live one? I’m not talking about source code changes, but, say, a new
ticket
type or SLA. Thanks for any thoughts.


Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

Hi Alex,

We use nginx to serve multiple independent installs from the same
server. The RT code + modifications is a pretty small footprint and
it allows us to have as full a test instance as we would care to
provide the resources.

Regards,
Ken

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

Do you run from source? If not, how did you direct RT to use alternative
paths during the install rather than using all the same ones and thus
failing to install or overriding existing files?

Were I to attempt a source install again, could I safely do so alongside
the current 4.2.8 instance on the server? Obviously I’d have to make a
different database, and couldn’t have both instances using the same email
addresses for sending/receiving, but what else would I have to consider?

Hi Alex,

Yes we do install from source and use /opt/rt3813, /opt/rt4210, /opt/rt441
as the install point based on the source. For the test instances we typically
configure their Email to deliver to a single file and we can check what was
sent within the RT history. Delivery could be controlled in many diffferent
ways based on the Email system delivery process.

Regards,
Ken

Hello all,
I finally have RT sending out emails on the company’s server, so we’re ready
to move forward with testing things and making changes. To that end, I’m
wondering how everyone manages testing changes without affecting the primary
instance, then moving those changes into production?

puppet, chef, ansible, cfengine, etc.

Unfortunately if you have never used a configuration management
system, then that adds an overhead cost to getting your RT test/prod
instances up and running.

-m