Version Control

For large instances with multiple administrators, we recommend you establish a version control system (VCS) to maintain your ScriptRunner scripts. Maintaining scripts within a VCS records changes to individual scripts over time, allowing you to revert changes and access old script versions if needed. When troubleshooting, the VCS history may contain meta-information on why a particular change was made, when it was made, and who initiated the change.

Below is an example strategy using the popular VCS Git for maintaining script versioning across your instance.

This is a suggested workflow. As each instance is unique, administrators should implement a strategy that works for them.

We assume readers have a basic understanding of a Git workflow and familiarity with a command-line interface.

Set up an account in a Git repository management solution (such as Bitbucket) for the server user.
Create a repository in the Git repository management software, and add read-only access for the server user account created in the previous step.
If you use a staging environment for testing, create a staging branch (which we will refer to as staging) from the master branch on the repository management solution. All script changes are first merged to the staging branch.
Run the following command on the server:
```
 
git clone <RepoUrl> <ScriptRoot>
```
On your local machine, clone the repo locally:
```
 
git clone <RepoUrl> <ScriptRoot>
```
Create a tracking branch off the staging branch. This new branch is your development branch. Make changes to the scripts using an Integrated Development Environment (IDE). For example, you want to fix a bug in one of your scripts so create a branch called bugfix/fix-null-pointer-exception.
```
 
git checkout -b bugfix/fix-null-pointer-exception origin/staging
```
Once all changes have been made locally commit them:
```
 
git add .
git commit
```

Push the changes for review:

 
git push origin HEAD:refs/heads/bugfix/fix-null-pointer-exception

Open a PR for review, targeting the staging branch.
Once the PR has been approved. Merge it into the staging branch.

It is possible to branch straight from master if a staging site is not required.
Test the staging branch on your staging environment. When the staging branch is stable and ready to move to production, create a PR from staging to master. Review the PR, and merge the changes to master.
To update production manually, log into the server, navigate to the script roots, and run git pull to refresh the local master branch on the server.

To ensure the Script Roots repository is always up-to-date, set up an automatic crontab rule to continually pull the master branch on the server. This approach means users do not need server file access as the master branch updates are automatically pulled.