Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance

by Herkum (Parson)
on Jul 11, 2006 at 13:30 UTC ( #560450=note: print w/replies, xml ) Need Help??


in reply to Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance

I wrote a bunch of tests that depended on a database for holding my data. The tests deleted all the rows from the tables that I was working with and then inserting the test data into the tables. If I did this against the production database I was going to delete the production data as well, that would be bad.

I decided to have a production and a test database. I wanted something that would be easy to include in my test code and would not require a major change in production code. I thought, if I am working with my test modules I make my DB connection code look like this what would I have to do.

use Base::DB::Connect 'test';

The only thing I had to do was include a import subroutine/method. It changed the $database variable from 'Prod' to 'Test' and I was done! I was happy because I did not have to change the code to support 'Test' and 'Production' as separate environments.

  • Comment on Re: Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance
  • Download Code

Replies are listed 'Best First'.
Re^2: Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance
by tphyahoo (Vicar) on Jul 14, 2006 at 09:58 UTC
    What is an "import" subroutine? Why did you boldface this term? Does it have a special meaning?

    What terms do I search the web on to learn more?

      It has to do with the use function, which is really just syntactic sugar. One of the things it does is to call the static import method on the package youíre loading, passing it the parameters you gave on the use line to process them. The common behaviour of import is to export functions from the package itís in into your current one, usually by calling upon Exporter. However, all of that is entirely conventional, and you can actually do whatever you want with those parameters Ė like using them as a names for configurations to choose between, as Herkum does.

      The use docs have the details.

      Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://560450]
help
Chatterbox?
[Corion]: Maybe the solution would be to launch a cron job every minute that takes two measurements a minute apart and sends a mail if the usage is below on the first and above threshold on the last measurement
[marto]: that's essentially it :)
[marto]: I think the long term solution would be to have sysadmins that do their job, so I don't have to do everything :P
[marto]: they already have an entire BMC patrol system, which they disabled, because it was sending out spurious messages. So rather than fix the issue, or even find out what it was, they turned it off. No messages, can't be any problems, right?
[Corion]: marto: But having open tickets / incidents increases the pressure on them ;) Of course, likely your contract / SLA specifies an upper limit for the number of incidents :-D
[Corion]: marto: Ow ...
[marto]: Corion They don't get into trouble for the number of tickets, or even breached tickets they have
[marto]: which is a core issue with the client
[Corion]: marto: Yeah, I can imagine that

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (9)
As of 2017-01-24 10:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you watch meteor showers?




    Results (203 votes). Check out past polls.