craychee · December 28, 2015 01:09 · dsdobrzynski · Nov 11, 2013 · generalredneck · Nov 11, 2013
diff --git a/Promet Development Workflow FAQ b/Promet Development Workflow FAQ
 ##Q. What are you doing to my site?
 ###A. We are adding an additional directory in front of your project root that contains executables that can build and configure a virtualized development enviornment that mimics your production environment as much as possible and that allow us to deploy changes to your site with a testable, repeatable, transparent process.

 ##Q. After you do this, will my site look or behave any differently?
 ###A. No. We are not altering your Drupal codebase or database at all. We making your current configurations (of content types, views, feeds, taxonomy vocabularies, roles and permissions, etc.) explicit by putting them into code. If we alter the configurations we will do so by altering that code so that our changes are explicit. Moreover, every one who works on your site will be able to test our configuration changes in the exact same way as we will be deploying it live. 

 ##Q. Why is this important?
 ###A. First, we want to ensure that changes that we make to the site are not dependent on a database. That means that we do not take a copy of your database, make changes to it, and then swap out the old database with the new (meaning that any changes made to your site--new articles, new users, etc.--would be lost in the turnover). That is not how we define development. If we need to change how Drupal is configured, we do that in code and leave your content alone.

 Second reason, a motivation that is less visible to clients, is that we want to ensure consistency. We want to make sure that if I make a change to the code base, it will behave for another developer making changes to the code base in the exact same way it does on my own computer. And on a development server. And, most importantly, on your production server. To do this, we essentially create a copy of your production server and develop and test our code on that server. We modify until we can do this over and over again and get the same results.

 Finally, we want to be able to recreate what a live deployment will look like. By tagging our releases and deploying our changes using executable scripts inside the code base, we can tell you with confidence what changed with every release. Making code changes allows us to version control the changes and keep track of the responsible developer for those changes.

 ##Q. We would like to make configuration changes to our site. Do we need to work this way?
 ###A. In a word: yes. Yes, as long as we are doing active development to your site. After pushing configuration changes in code, we restore all configurations to their default. This is the equivalent of returning your phone back to its "factory settings." If you have altered the "factory settings" in the interim, you need to tell us and accommodations can be made.

 ##Q. When you say you restore to "factory settings" does that mean my content will be blown away?
 ###A. Absolutely not. Users, nodes, and taxonomy terms are not configurations and are not impacted unless there is an explicitly stated use case. If you alter the way that your nodes, users, and taxonomies are configured (removing a field, altering a view, altering a context, etc.), a strategy can and must be put into place to ensure that your changes are accommodated.
	##Q. What are you doing to my site?
	###A. We are adding an additional directory in front of your project root that contains executables that can build and configure a virtualized development enviornment that mimics your production environment as much as possible and that allow us to deploy changes to your site with a testable, repeatable, transparent process.

	##Q. After you do this, will my site look or behave any differently?
	###A. No. We are not altering your Drupal codebase or database at all. We making your current configurations (of content types, views, feeds, taxonomy vocabularies, roles and permissions, etc.) explicit by putting them into code. If we alter the configurations we will do so by altering that code so that our changes are explicit. Moreover, every one who works on your site will be able to test our configuration changes in the exact same way as we will be deploying it live.

	##Q. Why is this important?
	###A. First, we want to ensure that changes that we make to the site are not dependent on a database. That means that we do not take a copy of your database, make changes to it, and then swap out the old database with the new (meaning that any changes made to your site--new articles, new users, etc.--would be lost in the turnover). That is not how we define development. If we need to change how Drupal is configured, we do that in code and leave your content alone.

	Second reason, a motivation that is less visible to clients, is that we want to ensure consistency. We want to make sure that if I make a change to the code base, it will behave for another developer making changes to the code base in the exact same way it does on my own computer. And on a development server. And, most importantly, on your production server. To do this, we essentially create a copy of your production server and develop and test our code on that server. We modify until we can do this over and over again and get the same results.

	Finally, we want to be able to recreate what a live deployment will look like. By tagging our releases and deploying our changes using executable scripts inside the code base, we can tell you with confidence what changed with every release. Making code changes allows us to version control the changes and keep track of the responsible developer for those changes.

	##Q. We would like to make configuration changes to our site. Do we need to work this way?
	###A. In a word: yes. Yes, as long as we are doing active development to your site. After pushing configuration changes in code, we restore all configurations to their default. This is the equivalent of returning your phone back to its "factory settings." If you have altered the "factory settings" in the interim, you need to tell us and accommodations can be made.

	##Q. When you say you restore to "factory settings" does that mean my content will be blown away?
	###A. Absolutely not. Users, nodes, and taxonomy terms are not configurations and are not impacted unless there is an explicitly stated use case. If you alter the way that your nodes, users, and taxonomies are configured (removing a field, altering a view, altering a context, etc.), a strategy can and must be put into place to ensure that your changes are accommodated.
No results found