Answers.Body: <p>In larger projects we tend to put configuration stuff (like setting up contact_sub_types, activity_type, case_types, groups, tags etc.) in a specific config extension that can then be deployed in each environment.</p>
  
  <p>When doing so we tend to put the configuration into json files. But there is nothing like features as far as I know.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-07T01:37:31.020Z
Answers.Text: so, basically a site-specific extension?
Answers.UserDisplayName: ryancross
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-10T07:02:03.657Z
Answers.Text: Yes, during the deployment process so the 'tested and confirmed' changes and setup from the sandbox can be implemented on acceptance and live? Once the main site is live a change management procedure for each change takes over?
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-06T07:12:01.083Z
Answers.LastActivityDate: 2015-08-06T07:12:01.083Z
Answers.UserDisplayName: ErikH - CiviCooP
Body: <p>I'm looking to set up best practices for a development workflow (i.e. dev > staging > production) </p>
  
  <p>In Drupal there is features, which allows you to export your configuration into code and then deploy it. </p>
  
  <p>What are people using when doing this in CiviCRM? </p>
  
Tags: <developer><deployment>
Title: What are best practices for deploying changes?
ThreadText: # What are best practices for deploying changes?
  
  (Asked by: username_0 on 2015-08-06)
  
  I'm looking to set up best practices for a development workflow (i.e. dev > staging > production)
  
  In Drupal there is features, which allows you to export your configuration into code and then deploy it.
  
  What are people using when doing this in CiviCRM?
  
  **Tags:** developer, deployment
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-08-06. Score: 1
  
  In larger projects we tend to put configuration stuff (like setting up contact\_sub\_types, activity\_type, case\_types, groups, tags etc.) in a specific config extension that can then be deployed in each environment.
  
  When doing so we tend to put the configuration into json files. But there is nothing like features as far as I know.
  
  > **Comments:**
  > **username_0**: so, basically a site-specific extension?  
  > **username_1**: Yes, during the deployment process so the 'tested and confirmed' changes and setup from the sandbox can be implemented on acceptance and live? Once the main site is live a change management procedure for each change takes over?  
  
  ---
  
  