Setting up a staged deployment environment using Git

Introduction

What are the best options for setting up a GIT staged deployment environment for separate development, test and production systems? There are many options available for setting up git repositories. We list four secure (private repository) options in order of increasing capacity: With the first option being local repositories on a shared drive for a small/medium team, and the final option being a commercial solution suitable for large companies with many projects and lots of repositories.

The first two options are the simplest, so we suggest that you try these out first.

All four options presented are suitable for sharing code in a staged development environment.

Take 5 to create your first repo [top]

To show you how easy it is to create a repository, we will create one in an empty local directory. This is not one of our “official” options below but it is very similar to the first option, except that we did not use a shared directory (to make it simpler).

The reason this is not an “official” option is because this article is all about collaboration and sharing project code, and you cannot share code in a local private repository.

Tip: A local private repository like this can still be useful for a developer. You may want to store your own utilities or code samples/templates (code that is useful to you, but not to others). Or perhaps your Iguana instance is getting completely choked up with 100s of channels, then you can export the ones you are not using to a local repository and delete them from Iguana (and import them again whenever you ever need to).

Create a repository using a local directory on your machine:

  1. Create a directory for the repository, we called ours my first repository.
  2. Open the Settings>Repositories page:
  3. Click the New Repository button.
  4. Enter a name for the repository, we used my-first-repository.
  5. Browse to find the directory you created in step one.
  6. Make sure that the Local protocol is checked.
  7. Click the Save Repository button:
  8. That’s it! You just created your first repository in a local directory on your machine.

To test the repository:

  1. Open the Settings>Export Channels page.
  2. Then export a channel to the new repository.
  3. Open the Settings>Import Channels page.
  4. Then import the channel you just exported.

What is staged deployment? [top]

So what exactly is a staged deployment environment? It is basically an industry standard practice of separating your development, testing and production systems.

When using Git with this model you can create development, testing and production repositories and move your code between them as it moves through the stages. This helps to make the whole deployment process a lot easier to manage.

Deployment stage Purpose Repository Description
Development Create and modify code
  • Local Iguana repository
  • Development repository
Coding is performed by a developer using Iguana on a desktop machine. The developer will commit changes in the Iguana builtin repository while working on the code. Once he is satisfied that the code is complete he will export changes to a shared development repository.

Some code testing will usually be performed at this stage to ensure it integrates correctly with (and does not break) other code. Any testing at this stage will have a technical code based focus and will be performed by another developer, or someone with a development background. Automated backtesting can also be performed.

Once the code is working correctly in the development environment it can then be exported to the testing repository.

Note: Some technical or backtesting can be performed at the next stage there there is no hard and fast rule, it is really what works best in your environment.

Testing Test code to ensure that if performs according to specification
  • Testing repository
More thorough testing is done at this stage, with a much more business and user oriented focus. Basically you want to make sure that all the data is processed correctly according to the business requirements.

Testing at this stage is often broken down into three steps:

  1. Integration testing to check that no side effects are accidentally introduced, will often include automated backtesting and/or be performed by technical users.
  2. Quality Assurance, where you test that the business requirements are met, probably performed by more business oriented users.
  3. Staging or Pre-production, where you test against a mirror of the production environment, this is basically a final test to ensure that code is safe to release, and usually involves production IT staff (DBAs, network admins, etc).

Once the code passes all the required tests then it can be exported to the production repository.

 Production Production code to keep track of code releases
  • Production repository
The production repository is used to track code releases. Only the production ready release candidates should be stored in the production repository.

To complete the release process the code will need to be copied to the live Iguana production server.

Note: Releasing code to live servers occurs after it is uploaded to the production repository, it could be days or even weeks later depending on business requirements.

Comparison table [top]

Repository type Ease of use Cost Secure? Usage Comments
1. Shared local directory Easy Free YES

Private

Small to medium projects Iguana service user needs access to the repository directory.

Data privacy/access is determined by the directory/share permissions.

2. Private online account Moderate Paid

(Bitbucket free for 5 users)

NO

Public

Medium to large projects and multiple projects Data is private to the repository users.

However you should check to ensure that the service provider is HIPAA compliant.

3. Open source local repository Difficult Free YES

Private

Medium to large projects and multiple projects Local IT expertise needed

Some tools require payment for commercial use.

4. Commercial solution Moderate Moderate YES

Private

Large projects and multiple projects Turnkey convenience, tools, help and support bundled together as a package. Suitable for large projects.

Data can be local or hosted online in the cloud.

1. Shared local directory [top]

This is the simplest option, you just use Iguana to create a repository using an empty local directory on a Shared Drive. This is useful for sharing code in projects with multiple developers. It’s also great for moving code between different instances of Iguana.

The user running Iguana must have access to the shared directory, see this FAQ for details: Windows: How to get the Iguana Service to Work with a Mapped Network Drive. The process is similar for other operating systems like Linux and Mac.

Tip: You can use SMB to access a shared directory from Windows, Linux and Mac for cross-platform sharing.

See this article (or google) for more information: Share Files Between Windows, Mac, and Linux

There is no GUI other than what Iguana gives out of the box, for simple scenarios this may be all you need.

And when you outgrow this solution it’s very easy to upgrade to one of the other options.

If you have any questions please contact us at support@interfaceware.com.

Create a repository using a shared local directory on your machine:

  1. Create a directory for the repository on a shared drive, we called ours my first repository.
    1. Ensure that the user running Iguana has read/write permissions for the shared directory.
    2. For Windows you will have to change the Iguana Service Logon to a user that has read/write permissions for the shared directory.
  2. Open the Settings>Repositories page.
  3. Click the New Repository button.
  4. Enter a name for the repository.
  5. Browse to find the shared directory you created in step one.
  6. Make sure that the Local protocol is checked.
  7. Click the Save Repository button.

Test the repository:

  1. First export a channel to the new repository.
  2. Then import the channel you just exported.

2. Private online account [top]

Use a private online Git account like Bitbucket or Github. Private online accounts are usually paid for, although some companies may offer some free users (at the time of writing the first five users were free at Bitbucket). This is useful for projects sharing code in projects with multiple developers. Online accounts are also automatically backed up so you are less likely to lose your work. Most online accounts have excellent web-based interfaces which make it easy to work with your repositories independently of Iguana.

If you have any questions please contact us at support@interfaceware.com.

Create a private online repository at a site like Bitbucket or Github:

  1. Create a private online repository.
  2. Open the Settings>Repositories page.
  3. Click the New Repository button.
  4. Enter a name for the repository.
  5. Enter the URL for the repository you created in step one.
  6. Make sure that the HTTPS protocol is checked:
  7. Alternatively can select the SSH protocol instead of the HTTPS protocol:
    Note: You will need to supply the private key that you are using with the repository.
  8. Click the Save Repository button.

Test the repository:

  1. First export a channel to the new repository.
  2. Then import the channel you just exported.

3. Open source local repository [top]

Run a “free” opensource Git on a local server. Git is installed on a local server machine that will contain the shared repositories. Git overhead is low so a dedicated server is usually not required. To simplify management the Git server should not be an Iguana server (particularly not a development server), this keeps a clean separation between shared repositories and any repositories you create with Iguana.

The “free” opensource option just means you don’t have to pay for the software. However you will have to pay for server administration, back up and maintenance. This option is really only viable for companies that already have an IT department, or at least a competent IT person.

You can use the Git command line interface to manage the server, or free tools like SourceTree or GitHub Desktop. There are many other tools out there some free and some paid, see The Git wiki: Interfaces, frontends, and tools for more information.

If you have any questions please contact us at support@interfaceware.com.

Create a repository on the server using Git command line tools:

  1. Download the Git installer for your  operating system https://git-scm.com/downloads
  2. Install Git it on your designated local server: https://git-scm.com/book/en/v1/Getting-Started-Installing-Git
  3. Use Git command line tools to create an empty “bare” repository: https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server
    • Use the bare option when creating the repository: git init --bare
  4. There are several options to share the repository: https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server
  5. Open the Settings>Repositories page.
  6. Click the New Repository button.
  7. Enter a name for the repository.
  8. Enter the details of the repository you created above, using one of these options:
    • Shared directory path
    • SSH URL
    • HTTPS URL
  9. Click the Save Repository button.

Test the repository:

  1. First export a channel to the new repository.
  2. Then import the channel you just exported.

4. Commercial solution [top]

Purchase a commercially supported GIT solution. Both Bitbucket or Github for instance offer commercial versions of their software that you can run within your own network. These and other suppliers can host repositories on a local server or in the cloud.

With the commercially supported option you pay for a supported turnkey solution that can support large complex projects (with many repositories and many users). If you decide to host the server locally (rather than on the cloud) you will still have to do some server administration. However the fact that the solution is commercially supported should reduce the management overhead. Once again this option is really for larger companies that already have an IT department, or at least a competent IT person.

You will be able to manage the Git server using the chosen front end, you will probably need to use the Git command line interface on some occasions.

If you have any questions please contact us at support@interfaceware.com.

Create a repository using your chosen graphical front end:

  1. Follow the install instructions from your chosen supplier.
  2. Use the Git front end tool to create an empty “bare” repository.
  3. Open the Settings>Repositories page.
  4. Click the New Repository button.
  5. Enter a name for the repository.
  6. Enter the details of the repository you created above, you will probably connect using SSH or HTTPS.
  7. Click the Save Repository button.

Test the repository:

  1. First export a channel to the new repository.
  2. Then import the channel you just exported.

Git References [top]

Leave a Reply