Configuration Management of Forms

  • Profile Image
    Asked on December 20, 2011 at 10:16 AM

    We installed and are self hosting the joform application and will want to have standard dev/test/prod environments setup for our forms and some form of configuration management/source control. Do you have a recommended approach for this and maybe a set of scripts (sql etc) to migrate forms through the environments?


  • Profile Image
    Answered on December 20, 2011 at 05:06 PM

    Hi Dave, 

    I will forward this query onto Aytekin. 

  • Profile Image
    Answered on December 21, 2011 at 01:53 AM

    Unfortunately no, we do not have an example source control system for forms. Since all information about forms is saved in database, taking regular backups should make it possible to restore a form later.

    You can also place the "cache" folder in a source control system and commit it regularly. The form builder first looks for a cached formID.js file which holds all information about a form in there. By restoring that file, and re-opening the form on the form builder, you can go back to a previous version. 

  • Profile Image
    Answered on January 05, 2012 at 08:19 AM

    Thanks Aytekin,

      As we will have separate apache/mysql for each of the environments (dev/test/production) can I therefore just copy the forms from the cache folder on dev across to the cache folder on the test and production environments and they will work or would I need to populate some rows in the test and production mysql databases also?

  • Profile Image
    Answered on January 06, 2012 at 03:43 AM

    The forms can be transferred like that between multiple environments, but the problem is that the my forms page does not use the cache. So, the user would not see the form on the other environments even though it is available there. 

    In your case, my suggestion would be something different: Use Mysql replication. If you can replicate the database from the dev -> test -> production, any changes you make on them will be replicated to the live site. 

    If you need to get the updates from the production database back to the dev/test databases, you can even do a replication loop. So, the production database would also replicate back to the dev database. 

    We do have a similar setup currently. We have the environments in 3 separate data centers. We replication database to database, then we replicate that to European database. Then we replicate that back to the main database. So, any change made on any of the databases are (almost) instantly replicated to the other databases. 


  • Profile Image
    Answered on January 06, 2012 at 08:23 AM

    Hi Aytekin,

    Thanks for the quick reply. Unfortunately I don’t think this approach will work as part of our release strategy.

    We need to move specific forms from dev to test as part of our release along with the current snap shot of our application code, we don’t want a constant replication as we need to be selective of what forms are deployed and when they are deployed. Also when deploying to production we will not  have access to the production box, we will bundle the jotforms and allow the infrastructure team install them as part of a documented process on the production server (this is for compliance).

    I don’t think a full db export from dev to test/prod would work either as I imagine the actual responses that are stored would also then be migrated across and may even overwrite the current test/production responses/answers table.

    Is there any other mechanism you think of we can use to allow us to achieve the above? I think a script/utility to create sql insert/update scripts from the dev forms db for the test/prod environments would be the ideal solution but I don’t know if this is feasible. We are using the jotforms product for the speed at which the tool allows us to create forms, so we don’t want to spend too much time developing a bespoke deployment mechanism if one already exists for our purpose.

    Many Thanks,