09-25-2014 11:25 PM
i am looking to implement version control for all SAS EG projects. Tortoise SVN is one such tool which supports SAS EG projects version control but it is open source. can any one suggest if there is any license product that supports sas EG versioning. any web link or article will be helpful.
09-26-2014 12:10 AM
Check this out - versioning with GIT:
We've very successfully used MS Visual Studio / Team Foundation Server with EG as well. The bottom line is you have to save your EG projects as external program (SAS text) files and then version control those. This is the only way to compare differences between versions, or to collaborate across a group of developers.
While it would in theory be possible to version control an EG Project file, only one person at a time would be able to update it, and there would be no way of comparing changes between versions.
09-26-2014 03:24 AM
Review your goal for version-control there is often a big misunderstanding.
Regulators are asking for being capable on underpinning having used the correct version of code in production environments. eg look at: AS/NZS ISO/IEC 27001:2006
You have to be able to do that by proving out of some logging / events / security protecting against updates. This is wit ITSM part of Release management and security with an RBAC implementation. Version control tools are having their goal on "collaboration across a group of developers" (thanks SASkiwi). That is an other stage another viewpoint.
Both are requiring you do something on your DTAP (Develop Test Acceptance Production) environments and processes.
The difference is as big as the difference between horizontal and vertical.
An EG-project files can use a lot of artifacts and they can be internal and external. Having them external you can make them a subject to version and release management.
The flow with dependendicies cannot made be external. When that is an important part you need to bring egp-projects under control.
SAS metadata objects, you are probably using a lot of them, are on the metadata side, You have to think on those at well.
For DI programming there is an option to integrate version control tools (Devlopment). But there is no standard release management approach.
Aside those there are possible many more artifacts to bring under code release management.
When you are needing release management to cover the "version underpinning of regulations" than there is a lot more work to do.
There was a time auditors did only ask you could make a backup. Being able to restore data was not relevant.
After some debacles they are now starting to ask whether you can prove you are capable to do a restore can do a DR (part of Business Continuity).