Hi All,
I have a question about Version Control tool. We are currently using Microsoft VSS for versioning our other code e.g. pl/sql, scripts. But for DataStage code we are investigating whether to use Version Control tool or VSS. I belive there is no check-in/check-out available in Version Control tool. Ours is a multi user environment and number of users can work on the same job for different changes. In VSS, we can store the dsx files in VSS and VSS will ensure that only one person work on the code as code has to be checked-in/checked-out by the user. But for version control is there any way by which we can ensure that changes made in a job in the development project cannot be overwritten by any one else?
Does anyone has some comparison about Version Control Vs. VSS.
Thanks in advance.
Harsh
Version Control Vs Visual Source Safe (VSS)
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
DataStage itself prevents more than one developer at a time from working on a DataStage job. It does this by the simple expedient of locking the job definition record for update within the DataStage Repositiory database. DataStage also keeps an audit trail of who modified each job, and when. Thus, there is no actual need for a check-in/check-out capability. The second developer gets a "job locked by other user" message when attempting to open the job design for editing.
It follows that there is no check-out/check-in capability in Version Control for DataStage.
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
It follows that there is no check-out/check-in capability in Version Control for DataStage.
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
Hi Ray,
Thanks for the reply. What I meant with more than 1 user working on a job is not at the same time but over a period of time. In our environment, if a user check out a code (say pl/sql from VSS), no other user can work on that code till the first user check the code back. This is required as changes made by the first user may be promoted first and the changes which second user wants to make will be promoted a later date.
The only concern we have with Version Control is if a user 'A' initialize a productive job to development project for making some changes which he wants to promote in couple of weeks (We do block point releases). Then user 'B' wants to make some changes to the same job and again initializes the job to developement project. This way user 'B' can overwrite changes made by user 'A'. With Check-in/Check-out process (for VSS), the users always first check whether the code is checked out by someone or not?
Thanks for the reply. What I meant with more than 1 user working on a job is not at the same time but over a period of time. In our environment, if a user check out a code (say pl/sql from VSS), no other user can work on that code till the first user check the code back. This is required as changes made by the first user may be promoted first and the changes which second user wants to make will be promoted a later date.
The only concern we have with Version Control is if a user 'A' initialize a productive job to development project for making some changes which he wants to promote in couple of weeks (We do block point releases). Then user 'B' wants to make some changes to the same job and again initializes the job to developement project. This way user 'B' can overwrite changes made by user 'A'. With Check-in/Check-out process (for VSS), the users always first check whether the code is checked out by someone or not?
Harsh,
You need to understand that the paradigm for Version Control is different than for something like VSS. As Ray stated, there is no check-in / check-out capabilities in the product. Working in DataStage is a little different from working in C++ or PL/Sql.
Back in the day when I used PVCS, you would have a code repository that you would "check out" code from to work on - into your own personal work area. No-one else could pull that code and do anything with it until you had (in some fashion) checked your changes back in.
DataStage (and you should as well) uses 'projects' to segregate development from qa/testing and production. Version Control adds a fourth project to the mix - it's own versioning project or repository. The difference here is you don't check things *out* to work on them, you check them *in* when they are ready to be elevated up the food chain.
Your developers work in the dev project, and as Ray mentioned, any job currently being edited is locked for the duration. True, it doesn't stop someone else from "working" on the same job during the times when the first user isn't actively accessing the job or jobs. We haven't had a problem with this arrangement, but then we're not in a *huge* environment... coordination of who is working on what when hasn't been a problem for us.
When the dev work has been completed, unit testing is done and it's time to uplift it into qa, then Version Control comes into the picture. Here's a suggestion as well - do *not* allow the developers access to Version Control - assign that "duty" to a dedicated person or persons so that you have control of it. We have a procedure that is followed and a request for Versioning is processed. Technically, we have a review (if needed) and then one of the people with access to VC (usually me) will import the job from dev into the Version Control repository. During that process, a history is generated and any change log type information you specify is recorded back into the job as well (in the Long Description, specifically).
From there, the job can be elevated from the Version project to the QA project and put thru it's paces. Assuming it passes muster, it would again be elevated, this time from Version to production. All of this activity would be logged in VC. Also note that this doesn't need to happen in a singleton fashion, but multiple jobs can be "batched in" if they were all part of a change event and then elevated in that same batch as well.
Needless to say, problems would be resolved by elevating "older" releases from Version Control back into where ever they are needed - production, for example, if the latest change was found to be defective only after it became the real deal, or back into development for more work. FYI - sometimes people don't realize you can "version" more than just jobs with VC. Routines, metadata and even o/s scripts can benefit from the same process.
Sorry to get kind of long-winded here, but I wanted to lay out the process we follow with Version Control so you could compare it to what you are used to (VSS) and see the differences. Hope this helped.
-craig
You need to understand that the paradigm for Version Control is different than for something like VSS. As Ray stated, there is no check-in / check-out capabilities in the product. Working in DataStage is a little different from working in C++ or PL/Sql.
Back in the day when I used PVCS, you would have a code repository that you would "check out" code from to work on - into your own personal work area. No-one else could pull that code and do anything with it until you had (in some fashion) checked your changes back in.
DataStage (and you should as well) uses 'projects' to segregate development from qa/testing and production. Version Control adds a fourth project to the mix - it's own versioning project or repository. The difference here is you don't check things *out* to work on them, you check them *in* when they are ready to be elevated up the food chain.
Your developers work in the dev project, and as Ray mentioned, any job currently being edited is locked for the duration. True, it doesn't stop someone else from "working" on the same job during the times when the first user isn't actively accessing the job or jobs. We haven't had a problem with this arrangement, but then we're not in a *huge* environment... coordination of who is working on what when hasn't been a problem for us.
When the dev work has been completed, unit testing is done and it's time to uplift it into qa, then Version Control comes into the picture. Here's a suggestion as well - do *not* allow the developers access to Version Control - assign that "duty" to a dedicated person or persons so that you have control of it. We have a procedure that is followed and a request for Versioning is processed. Technically, we have a review (if needed) and then one of the people with access to VC (usually me) will import the job from dev into the Version Control repository. During that process, a history is generated and any change log type information you specify is recorded back into the job as well (in the Long Description, specifically).
From there, the job can be elevated from the Version project to the QA project and put thru it's paces. Assuming it passes muster, it would again be elevated, this time from Version to production. All of this activity would be logged in VC. Also note that this doesn't need to happen in a singleton fashion, but multiple jobs can be "batched in" if they were all part of a change event and then elevated in that same batch as well.
Needless to say, problems would be resolved by elevating "older" releases from Version Control back into where ever they are needed - production, for example, if the latest change was found to be defective only after it became the real deal, or back into development for more work. FYI - sometimes people don't realize you can "version" more than just jobs with VC. Routines, metadata and even o/s scripts can benefit from the same process.
Sorry to get kind of long-winded here, but I wanted to lay out the process we follow with Version Control so you could compare it to what you are used to (VSS) and see the differences. Hope this helped.
-craig
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
I have one client site where they keep everything read-only except in Version Control; anyone wanting to work on a component has to promote a new version into development (!) which is not read-only. They have a couple of extra functions for toggling the readonly field and a tight set of management practices to help to achieve this. To me it seems to be overkill, but it's doing what they want.