Feature Driven Development

 

When migrating to featured driven development, the goal is to make syncing of difference instances of a site as effective and efficient as possible. To accomplish this, we discipline ourselves to make ALL changes happen in code. This can take place three different ways:

Export components using the Features Module - Using this module we can export our views, context, variables (strongarm), blocks (boxes), and more. Anything that can be exported should be exported. You should build your features in logical groups. For example, if you are “featurizing” an events calendar, you would put the event content type, views for the calendar, context for the page, and permissions related to the events content type only into a single feature. Nothing that is not related to the events calendar should be in the feature and nothing that is related to the events calendar should be in another feature. If you come across a particular module that doesn’t support features you have a few options:

• Double check the issue queue on drupal.org. Chances are there is already an issue about integrating with the features module. Use your best judgement, but it’s ok to use a dev module or even some patches if it gets your components in features. It’s just your responsibility at that point to keep up with that modules & issues development.
• If there isn’t an implementation of features integration or any progress worked toward it, implement it yourself using the ctools api. This of course depends on the skill of your developers and how well you want to get invested into contributing on drupal.org. If you have the time and willingness, adding export support via ctools will provide great karma in the Drupal community for the developers and company.

Export components or data using the Drupal api

Manually make changes in an update script

1. Using module_enable to turn on new features you have commited to code
2. Update module settings that are not exported or stored in system variables.
3. mass update node / entity data
4. modifying system variables that are not exported
   1. * There are some variables that live in a very dynamic state as in there are some points where these variables exist and other points where they don’t. Special variables like this should not be exported to code using features.
5. Anything else you can quantify into programming / sql updates but can’t be exported.

---

• Bob’s Local - this is on Bob’s local computer
• Jennifer’s Local - this is on Jennifer’s local computer
• Development - this is on the development server and used for the team to check their cumulative work.
• Staging - this is on the development server and used for the client or upper ups to sign off on work complete
• Production - this is on the production server.

1. On Bob’s local instance, he is going to create the initial feature:
   1. First he will download any new required modules.
   2. Next he will create the new content types, views, context, etc and will get a working prototype of the events calendar working on his local.
   3. Next he is going to create a new feature exporting all those new components he just created and will upload that feature back into his sites/all/modules/features/ directory
      1. * This is just a nice standard to keep to organize your site. If you haven’t implemented this from the start, don’t sweat it, you can upload your feature where ever a normal drupal module would work:
         1. sites/all/modules/contrib
         2. sites/all/modules/features
         3. sites/all/modules/custom
   4. Now, he is going to create a new update script in mysite_updates.install that will turn his feature on, and any new modules that were downloaded.
   5. Next he will commit any new modules, his feature, and his update script to version control and push.
2. Bob will then tell Jennifer that he has pushed his feature and it is ready for her themeing.
3. On Jennifer’s instance on her local machine, she is going to update her repository with the latest code that was commited.
4. Now that she has the new code, she is going to run her update.php to run any update scripts
   1. If you are using drush, you can run ‘drush updb’ to perform these updates.
5. At this point, she should have the same exact events calendar feature on her instance that Bob had on his, minus any dummy content. It is now ready to theme.
6. Jennifer is going to create a mysite_events_calendar.css file in the features directory with the css for the feature.
7. Next she is going to add an implementation of hook_init() to her mysite_events_calendar.module that includes her css file.
8. Now that the feature is themed on her local, she is going to commit her css file and her changes to the .module file.
9. The team lead will run a version control update on the development server instance which will pull in:
   1. The new modules bob commited
   2. The feature bob commited
   3. The update scripts to turn it all on that bob commited
   4. The css file for the feature that Jennifer commited
   5. The update to the features .module file that Jennifer commited.
10. Next the team lead would run update.php on the development instance which would run the update script that bob commited, turning on the feature and related modules.
11. Again, if you have drush, you can use ‘drush updb’ to do this.
12. The project manager may notice that the events listing is sorting incorrectly. The task will be handed back to Bob to correct.
13. Bob will update his local repository to grab any other changes.
14. Bob will then (on his local instance) manually update the view via the views UI and save the changes.
15. Now if Bob goes to the features UI, the events calendar feature will be listed as “Overridden” because he has made manual changes in the database that differ from what is exported to code. Now bob needs to save those overriden changes to code to get the feature back to a default state. To do this he has two options:
    1. If he is not using drush, he will edit the feature and click the “recreate” button which will redownload the feature with the latest changes. He then just needs to reupload those files back to his local instance.
    2. If he is using drush, he can run the feature-update or “fu” command which will write those database changes directly to code in place. He would do this by running the command “drush fu mysite_events_calendar”
       1. This command can only be run if you are MODIFYING existing components in the feature. If you need to ADD new content types, views, fields, etc to a feature, you have to do it via the “recreate” ui.
16. Now bob has code changes in his feature that he will commit and push
17. Now the team lead will go to the Features UI page to make sure the feature is in a “Default” state. If for some reason the feature changes via the code caused it to be overridden, then the team lead would “revert” those changes to what is in code (what bob just commited). Generally features should just be already default even with the new code changes.
    1. Using drush you can also revert features by running the command ‘drush fr mysite_events_calendar’
18. The team will then test the changes on the dev server.
19. The team lead will run the version control updates and then update.php on the staging server.
20. This will pull in all the changes and updates.
21. It is now ready to be tested on the staging server.
22. If there are any issues, the team would go back to step 5. - b.
23. If the the feature looks good on staging it is now ready to push live.
24. Now that the feature is “complete” it is ready to be tested on the Development server by the team
25. At this point, the development server will have an enabled events calendar with all the theming ready for testing.
26. Back on the Development Server the team lead will run a version control update to grab the new code changes bob commited. It is also generally a wise idea to run the update.php script just in case there were updates commited. If there are not then nothing will happen.
27. When the team lead / project manager is happy with the results, the changes will be pushed to the Staging instance.
28. Steps 1-7 can be completed for a number of features at time. Once staging is at a good point to go live, you can TAG staging with a milestone number.
29. On the Live Server the team lead would checkout the version control tag and run the update.php on the live server.