Team-Based Web Development Workflow

Infrastructure

For teams working in a single location, the repository should probably be located on a server on the local network. For many organizations, network security may not be an issue, in which case the SVN network protocol (svn://) will provide the best performance. If network security is an issue then the svn+ssh:// or https:// protocols may be a better choice.

If members of your project (such as external contractors) work off-site then you will probably need to serve your repository using HTTP with Apache. Whether you use http:// or https:// will depend on the sensitivity of your project. If you are working on a commercial project then https:// will probably be a requirement.

Most web development projects cascade their development process across development, staging and production servers. In such projects the development server may be a good candidate for repository server.

Smaller web consultancies may find hosting an attractive alternative. Numerous providers (such as Beanstalk) provide inexpensive hosting plans to organizations which may meet your needs. Hosting may be of particular interest to small, loosely-knit organizations which do not have or can’t afford a shared IT infrastructure.

Organizaton

It may be useful to define the roles played by the members of your team. You can use these roles to define authorization policies for your repository. Candidate roles may include:

Workflow

  1. The release manager checks out a working copy to the staging server. This will not be used for active development, but using a working copy will simplify synchronization with the repository.
  2. Each web developer checks out all or part of the website/app to their Mac. They use a local development server using their Mac’s built-in Apache instance. MAMP is also a great way to run Apache and MySQL on a developer’s Mac.
  3. Contributors make local modifications to their working copy as they work on the site.
  4. Once a task has been completed, changes which have been made by other team-members are obtained by updating the working copy. The web developer can inspect other’s changes and decide to update as much or as little of his working copy as is required.

    While it may seem counter-intuitive to pull changes before pushing them upstream with a commit, this workflow helps minimize conflicts and decrease merge effort.

  5. The committer resolves any ensuing conflicts and verifies that the result of the merge of the HEAD (i.e. latest in the repository) and local changes works as expected.
  6. The committer then commits the merged changes back to the repository.
  7. Server hooks (or Cornerstone post-commit scripts) can be used to notify other team members if necessary that new code has been committed to the repository.
  8. Once the project is ready for publication to the staging server, the release manager manually creates a tag in the repository. The frequency with which this step is performed will depend on the size and phase of the project. For example, during prototyping, the client may request that the staging server be updated daily, whereas during development it may be done on a weekly basis.
  9. The release manager then synchronizes the staging server with the repository by updating the staging server’s working copy.
  10. Any issues which are isolated by clients or users on the staging server can be fixed in-situ if necessary by modifying the staging server’s working copy. Once approved, these changes are then committed back to the repository.

    Developers should not attempt to access the working copy on the staging server remotely from their development computers. Instead they should use a remote shell (e.g. using SSH) or establish a remote desktop connection (e.g. using VNC) to work on the staging server. The svn command-line tool can then be used to commit changes back to the repository if the server is not running macOS Server.

    If larger modifications are required then they should be assigned to developers for implementation in their standard development environment.

  11. Once the website/app is ready for publication to the production server, the release manager creates a tag in the repository for that version. For major releases, she also creates a branch.
  12. The release manager then exports the project from the repository onto her computer and then either uploads the site to the production server in its entirety or uses rsync (or similar tool) to synchronize the production server with the exported project.

    It is very important that the release manager publish files exported from the repository rather than from a working copy. Working copies contain hidden .svn directories which contain duplicate copies of all files. These files do not need to be published to the production server and will have a negative impact on upload/synchronization times.

    Furthermore, working copies may contain additional files which, for security reasons, should not be deployed into a production environment where they are at risk of exposure on a public network.