If you are familiar with Git and/or GitHub, then you might want to use that for version control.
With Git, each developer has their own copy of every resource, so they can always work locally without having to access online resources directly. However, before you start working with a local resource, you have to make sure that it is up to date, so you ask GIT to fetch the most recent version from the common server (which only tracks versions and changes). And once you’re done working with a resource, you commit it to that common server, which makes it the most recent version for all to use. You can commit it to the main trunk of development or to any specific branch, which can be merged to the trunk or to another branch later on.
It sounds complicated but it actually is a pretty simple and straightforward process… that is, until you run into conflicts. Those conflicts are generally due to users failing to either fetch or commit properly, which leads to conflicting contents between two versions of the resource. When that happens, you usually have one developer in charge of resolving those conflicts which can sometimes be a painstaking process. Often times, it’s easier to revert back to the last known valid version and redo the work, or to accept one of the versions as the new updated version and then ask the other coder whose changes were rejected to integrate once again their own changes into that updated version.
Using GIT allows several users to work on different resources simultaneously, that’s easy. But if several users have to work on the same resources at the same time (think, for instance, of different Workflow Processes being worked on separately but that are ultimately intended to be run inside a single config), then you have to plan things carefully. In our case, here’s how we use it to manage some of our OL Connect-based solutions (the ones available on demo.objectiflune.com):
Coder 1: works on POD processes
Coder 2: works on AR processes
Coder 3: works on CM processes
All three of us work on a different Workflow config, containing only our own stuff. When we are ready to put all of them on the test server, we each commit our config to GIT. Then one of us logs on to the test server and fetches all three configs from GIT. That person then opens Workflow and imports all three configurations into a single config. Of course, we have all previously agreed on a naming convention to prevent any naming collisions in our processes and variables, and we have also engineered the system so that common folders also follow a set hierarchical structure.
In order to accommodate for the dev/test/prod environment, we commit to and fetch from different branches in Git. This allows us to “promote” a test branch to production status and it also allows us to go back to a previous version if anything went wrong while upgrading our resources.
This is just a very broad overview of how we work, there are a number of additional details that also come into play, but it should give you an idea of the kind of process you will have to plan for if you want to work concurrently on different resources and start managing versions of those resources.