Development environment and best practices

We discussed some considerations regarding your server environment and required resource levels. Closely related to that topic is the matter of determining the development environment and code management practices.

In almost every situation, you will want to create a development environment where you can safely implement and test your CiviCRM implementation without impacting your production site. Even if you are not planning to customize CiviCRM in any way, it is still worth creating that development environment where features can be tested, data imports can be reviewed, and you can safely explore different configuration options without risking disruptions to your production site.

Larger organizations, especially those that have planned a phased rollout of their CiviCRM implementation, will likely want three environments:

• Development: This is where all active code development takes place and where new features are first implemented and tested
• Testing/staging: As the development space is the sandbox for developers and may sometimes get dirty, it is useful to have a testing or staging server where non-technical staff can be involved in feature testing and quality assurance review
• Production: Once features have been developed and tested, they can be implemented on the production site and become actively used

In addition to determining how your site environments will be structured, you will want to give some thought regarding how your code is maintained. Unless you are a small organization with no significant code customizations, you will almost certainly want to manage your code in a version control system (VCS).

Currently, the most popular VCS in the open source world is Git. Git is a distributed system, which means each code repository is independent of the others. In other words, there is no rigid central repository that code must be checked in and out of. For this reason, it is attractive for development projects where there are multiple contributors who may or may not be located in the same location. The distributive nature provides more flexibility than a more centralized system.

The benefit of a VCS such as Git is the ability to track the history of every change in the files maintained in the repository. If you implement a new custom feature today, you would add the changes to the repository and commit them. Two months from now you might expand those features and commit the updated files. A month later you realize there was a conflict with another area of the site created by those changes. Because your code was maintained in a VCS, you can review the history of changes and more easily identify where the problem may have crept in.

Even if your customizations are minor and changes are infrequent, it is worth considering placing your code in a VCS. Work with your developer to devise an effective plan for managing the code as you move forward with the project.