One of the goals of a continuous controls monitoring (CCM) program is to monitor certain key accounting controls so that external auditors do not have to. We would like the external auditors to be able to rely on our work and test the responses to the identified exceptions rather than perform a large test once per year. Naturally, if an external audit firm were to rely on our testing, they would need some assurance on the integrity of the script code used to perform the test. We do use a version control system, right?
We use ACL for our data analysis and employ AuditExchange to run our CCM routines. Conspicuously absent from ACL’s development suite is any notion of version control and change management. But, it’s not like we are a professional IT development team, we don’t need to use things like Git for version control and change management, right?
The answer to that depends on how seriously you want your data analytics function to be taken. While we are not programming in Java, C++, Objective-C, or some other professional programming language, our output is code – script files that are designed to perform data analysis as autonomously as we can make them. And because our output is code, it is increasingly becoming my opinion that we should behave like professional programmers and employ controls and best practices used by our professional programming brethren. We would expect change management and version control of our own internal IT departments; shouldn’t we hold ourselves to the same standard we hold everyone else to?
After thinking about this, I decided to implement Git to version control the entire shared ACLScript code base. Employing this control has stabilized the code base because all changes must go through me. This prevents nasty issues like scripts changing unexpectedly because someone updated a production script on a shared drive. It will also reduce the number of questions I receive about scripts I have never seen which do not seem to work as intended. I am looking forward to the day I can fully shoulder the blame for a non-working script because that script was vetted by me before being committed to production. I do not like being blind-sided by an unstable code base, and it hurts the entire department’s credibility when something does not work properly. I think every auditor should learn ACL and understand its scripting environment. I happily mentor and encourage auditors to improve their understanding of ACL, but shared production code is never an appropriate place to learn.
What follows are the detailed steps needed to set up and begin using Git to manage changes to our scripts. This post details only the installation of Git – a second post will describe how I use it for ACLScript development. It took time and lots of trial and error to gather all of the pieces together to make Git work with my ACL development; I hope these instructions can make it relatively painless for you. This next section may be a bit verbose; I am writing it to my past self who knew nothing about Git.
What you need:
You need admin access to a server. You should already have your own application server, whether it’s a physical server or a virtualized server managed by IT. If you do not have one, get one. Virtualization is easy and storage is cheap; there is no excuse not to have one. I used the server that runs our installation of AuditExchange to store my script library. It is a Windows server. I am (mostly) a Windows guy. Unless stated otherwise, these posts assume a Windows environment.
Installing Git on the server:
Git can be downloaded from https://git-scm.com/. There is a nice, big button that says ‘Downloads for Windows’. Clicking on that should automatically download the latest version.
Log in to your server as an admin and install Git. I used all of the default settings in my installation.
After Git has installed, create a folder that will serve as the root of your repository. The folder’s name should end with ‘.git’. The example I will use here is ‘D:\MyNewRepository.git’.
Right-click on the new folder and select ‘Share with’ -> ‘Specific people…’
Enter your user ID and click ‘Add’.
Give yourself Read/Write access. When you make updates to the repository, you do so with your own user ID. Repeat this process for all developers who will be updating the repository.
When you have added everyone, click ‘Share’, then ‘Done’.
Now we need to run a command using a command prompt – you know, the old DOS-style way of doing things. This is the only time during installation that you will be using it, and the command is easy. Run cmd.exe.
Change the directory to your repository folder. In this example, we created our repository at d:\MyNewRepository.git, so the command you need to run is:
Note: If the command prompt is not pointing to the repository’s drive, you will need to direct it there before using the CD command. In our example, the repository is on the D: drive, but the command prompt starts at the C: drive. To direct the command prompt to the correct drive, type in the drive letter followed by a colon and press ‘enter’. In this example, we would type ‘D:’, press enter, and proceed with the CD command.
You will need to know where you installed Git for the next command. Type in the full path to the Git executable, followed by ‘init ––bare’. In this example, Git was installed at ‘C:\Program Files\Git’, so the path to the Git executable was ‘C:\Program Files\Git\cmd\git.exe’. Thus, the final command looks like this:
“C:\Program Files\Git\cmd\git.exe” init ––bare
Press enter. You should receive a message that says “Initialized empty Git repository in d:/MyNewRepository.git/”
We are almost done on the server. One last thing to do is to create a second folder to store the most recent version of our scripts so they are accessible to ACL. Git stores files in a way that we cannot access them from ACL. For example, if we had a script called ‘MyAwesomeScript.aclscript’, we could not run this command from ACL:
There is nowhere in MyNewRepository.git where a plain-text, easily accessible version of the script is stored. To make our scripts accessible, we need to create a bash script to copy the most recent version of all of the repository files to a second folder when the repository is updated. This second folder becomes our production script library. In this example, let’s create a new folder at d:\MyNewRepository. Notice there is no ‘.git’ after the folder name. I keep the repository and library folder base names the same; the only differentiation is ‘.git’ after the repository name.
The script library folder at d:\MyNewRepository needs the same developer permissions as the Git repository. When Git copies files from the repository to the script library, it does so using the permissions of the user making the change. You should also add Read permissions to anyone who will be using the scripts in ACL.
We now need to create the script that makes the updates to the library. Go to d:\MyNewRepository.git\hooks and create a file called ‘post-receive’. It is very important that this file have NO file extension. Open ‘post-receive’ in a text editor and paste in the following code:
while read oldrev newrev ref
branch=`echo $ref | cut -d/ -f3`
if [ “master” == “$branch” ]; then
git ––work-tree=//ServerName/MyNewRepository/ checkout -f $branch
echo ‘Changes pushed to production.’
Change ServerName to your actual server name, save the file, and close the text editor.
Congratulations! Git is now installed on the server and an empty repository is ready. To actually use Git to manage your code base, I recommend installing a GUI application on your local PC. Git can be run using command prompt, but I much prefer a graphical interface even if it sacrifices a bit of power. I simply do not have enough time in a day to memorize all of the Git command-line commands, parameters, options, etc. I use a program called SourceTree, made by Atlassian. If you use a different application (or the command prompt), the concepts will be similar but the GUI will obviously be different.
Creating a development repository on your local PC using SourceTree:
This next part is easy. Run SourceTree. At the top of the screen is a toolbar where you will find a button called ‘Clone / New’. Click it.
You will be presented with a ‘Clone / New’ dialog. Make sure the ‘Clone Repository’ tab is selected (a), Select the path to your server repository (b), and optionally select a custom path for your local repository (c). If SourceTree recognizes the server repository as a Git repository, it will say so at ‘Repository Type’ (d).
Click ‘Clone’. You will now see a new repository on the left sidebar in SourceTree. A new folder will also be created at the destination path you selected in the dialog. This new folder becomes your local development area. Any time you create, delete, or change something you will do it in this folder. As a developer, the only interaction you will have with the server folders will be to push your changes to the server. You will never edit files on the server directly.
That about wraps up this post. At this point you have a server repository that is version controlled by Git and a local development folder where you can perform development work without impacting existing production code. The next post will walk through some basic examples of how I use Git and SourceTree during development.