05-30-2015 02:50 PM
This question is even more difficult topic as the technical SQL environments and SQL behavior.
The question of wanting to know the modifications by who why what where and when is often coming from compliancy questions. It is about knowing the program-logic being used in production environments with the real production data and how that has changed by time.
The confusing question here is they want to know the "used versions" of the programs/code (the 5 w's).
>> This is covered by release and change management.
The result is a mandatory segregation of the business programs (applications) in DTAP stages (promote/deploy copies) with an according segregation of the business data with DTAP indication (kept segregated no copies between those stages).
This is the vertical line of lifecycle management.
The misinterpretation is caused by asking the "used versions" as ICT nerds are thinking that the word version has to be solved by a version management tool.
A version management tool has the goal of segregation the work of coders/developers so they cannot fight on who did the last update that should get passed some day into production after having been validated. If you have many developers around that are not able to communicate than you could need this.
This is the horizontal line of lifecycle management.
Your question doesn’t make sense for developers you cannot control those guys every minute thought and action.
Following the wrong line (horizontal) doesn’t help to solve to real question/requirement as it is in the vertical one.
Sorry Tom seeing your answer I made you a nerd showing that pavlov confusion reaction.
Let us focus on the vertical line of life cycle management. This release and change management is covering that with the isolated DTAP area-s.
Having those DTAP stages isolated and developers can only change things at D, your question get more meaningful by wanting to know by the 5w’s for a promote and deploy.
>> The most important one is that promote/deploy to production. Have that documented and your question is solved. The technical approach on .sas is a minor detail.
>> The minor detail on technical behavior .sas files:
An easy approach is to concatenate the DTAP locations as needed for each environment. http://support.sas.com/documentation/cdl/en/hostunx/67464/HTML/default/viewer.htm#n1cwdt7h01vaken0zl... (concat is supported in all environments disk-access) The advantage with that is you can prevent the need for copying all code back to developers location just because he needs to run (program-test) something. A developer that doesn’t validate code by running that is a bad one.
With this easy approach you are needing person(s)/roles and a process to support that. You will always need that.
Not sure about DTAP? See: http://en.wikipedia.org/wiki/Software_deployment
05-30-2015 03:07 PM
Additional information the question of compliancy is coming from eg iso27002:2013 (often used by regulators)
As those guidelines are that clear what should be solved and what controls / guidelines, my question would be why are they ignored that much?
14.2.2 System change control procedures
/./ Changes to systems within the development lifecycle should be controlled by the use of formal change
/./ Formal change control procedures should be documented and enforced to ensure the integrity of system, applications and products, from the early design stages through all subsequent maintenance efforts.
14.2.9 System acceptance testing
/./ Acceptance testing programs and related criteria should be established for new information systems, upgrades and new versions.
12.5 Control of operational software
12.5.1 Installation of software on operational systems
a) the updating of the operational software, applications and program libraries should only be performed by trained administrators upon appropriate management authorization (see 9.4.5);
b) operational systems should only hold approved executable code and not development code or compilers;
c) applications and operating system software should only be implemented after extensive and successful testing; the tests should cover usability, security, effects on other systems and userfriendliness and should be carried out on separate systems (see 12.1.4); it should be ensured that all corresponding program source libraries have been updated;
d) a configuration control system should be used to keep control of all implemented software as well as the system documentation;
g) previous versions of application software should be retained as a contingency measure;
h) old versions of software should be archived, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data are retained in archive.