How can you move ur project from development to production

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
akash_nitj
Participant
Posts: 27
Joined: Fri Aug 13, 2004 3:36 am
Location: INDIA

How can you move ur project from development to production

Post by akash_nitj »

Hi
Will appreciate if you can give my information or any related documents about how to move your project(from development to production ). What all necessary things need to be done.

Waiting for a response...................

Regards
Akash
anupam
Participant
Posts: 172
Joined: Fri Apr 04, 2003 10:51 pm
Location: India

Post by anupam »

Use of Version Control for promoting the Applications from development environment to production is the best method. If you don't have version control then may be you can use export import.

Please ensure that the applications /jobs promoted to Production should be Read - Only.
----------------
Rgds,
Anupam
----------------
The future is not something we enter. The future is something we create.
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Exactly. A search of the forum for "Version Control" will yield many posts on the subject... most of them actually helpful. :wink:

And you do have it, even though it is not installed by default. In version 6 you needed to 'explore' and find in on your cdrom yourself. In newer versions they finally included it on the Autorun menu.
-craig

"You can never have too many knives" -- Logan Nine Fingers
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

I would be reluctant to advise anyone to move straight from development to production; I would always advocate an interim Test/UA/QA environment.

For each environment (development, test/UA/QA and production) you require a DataStage project. Have you created these, and created in them any settings you require (such as uvodbc.config entries)?

Version Control is the appropriate mechanism. It requires a project of its own, the suggested name for which is VERSION, but which in reality can be called anything you like that is a valid schema name; I normally use VersionControl as the name for the Version Control project.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

ray.wurlod wrote:I would be reluctant to advise anyone to move straight from development to production; I would always advocate an interim Test/UA/QA environment.
As would I! I just made the assumption that there was stop along the way between development and production for testing.

In version 6.x you are pretty much stuck with VERSION for the project name, unless you know the 'trick' to get it to ask for it. It wasn't until 7.x that they added the ability to easily support multiple or alternately named version control projects.

The trick, by the way, is to purposely flub something about the connection to the VC repository. After the error is aknowledged, you will get the standard connection dialogue which includes the project name to connect to.
-craig

"You can never have too many knives" -- Logan Nine Fingers
vmcburney
Participant
Posts: 3593
Joined: Thu Jan 23, 2003 5:25 pm
Location: Australia, Melbourne
Contact:

Post by vmcburney »

A little advice for getting started with the version control tool, when learning how to use it you tend to add junk to your VERSION repository and your development job description fields. It took me quite a few goes at initialisation and promotion before I worked out how the tool would support a release methodology with standardised numbering and comments.

To avoid getting junk in your development area create a new project and import some development jobs into it. Practice using VC against these jobs. When you have got the hang of it delete your practice project and your practice VC repository and create a new one.
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Ah, yes... excellent advice. :lol: You don't necessarily need to do this in a different project. Once you are done playing with a few jobs and Version Control, you could simply delete and recreate the VERSION project and then go back and scrape the VC log information from the Long Descriptions of the jobs you'd been playing with.

Something to realize - you can have more than one VC project. 8) We, for instance, have 12 projects for our jobs - 4 logical Subject Area groups, each with a dev, test and production project. This means we also have 4 version control projects - one matched to each logical Subject Area. However, it does take a little more work (and attention) to make sure you are hooking to the right VC project for your work... not that I've ever goofed up and used the wrong repository or anything. :oops: Heck no. Not me.
-craig

"You can never have too many knives" -- Logan Nine Fingers
Post Reply