Revision Control
Data collection in Causal is completely specified by your FDL file, which is just another source file that is committed into your revision control system. This has a couple of major advantages.
Any changes to your data collection spec can go through your current software development process. That means you can catch bad specifications during code review, compare what's changed between different branches of your code, and revert back to old versions if required.
Unlike other systems, Causal versioning is simple to reason about because Causal versioning is your versioning. In Causal, both the data specification and code that uses the specification live in the same branch in your repository. If you want to know which version of the data collection is running in production, just look at the production branch.1
Other systems have to rely on complicated versioning schemes in order to manage the connection between your code and the data collection back end. You need to synchronize the versions manually which is tedious and error prone.
Environments
An environment in Causal describes either a staging or production environment for your code. For example, most organizations will have at least two environments. A development environment for integration testing and a production environment where the actual live application runs. Of course, you can have as many or as few as you like to support your development workflow.
Each environment is associated with a branch in your revision control system. Causal can automatically configure an impression server to collect and serve data for each environment, as well as create a data warehouse to hold the data. The version of the FDL file on the environment's branch defines how data is collected and logged.
- Causal integrates with your revision control system so that when you launch your production server it automatically gets the spec from the correct branch in your revision control system.↩