The features module is great for managing Drupal projects.
Graphical development in a CMS like Drupal 7 is wonderful. It is possible to develop complex sites with very little coding. It is also great for getting started, especially for small sites. The anxiety begins when the site starts getting larger—and there's a set of developers, not just you alone.
As the complexity of the site increases, you need to separate the development environment from the production environment. You may want to have a separate testing environment as well. For development, you need minimal representative data. For testing, you may need simulated data in order to test for scalability and performance. The last thing you want, as a developer, is to be remembered for messing up live content—and the safest way to ensure that doesn’t happen is to stay away from the operational site!
Since the data about the site and the content are in the same database, you may want to selectively back up and restore parts of the database. However, it is usually simpler to do the development, and when everything is working well, repeat the steps on the test and the deployment sites.
If the steps are being repeated, how do you ensure that no PousH FOLFk oU fiHOG HnWUy Ls GLIIHUHnW Ln WhH OLYH sLWH IUoP WhH development site? And later, when multiple developers are involved, you will need to know who did what, and when.
How do you keep track of features being added to your site? It would be much simpler if the changes you make in Drupal 7 using the graphical interface could be saved as a text fiOH, whLFh FouOG bH usHG Wo LPSOHPHnW WhH sDPH FhDngHs Ln the test and deployment servers. You could further implement source code control using a repository like Git or Subversion. This is what you may do with UML modelling tools like ArgoUML, or form design tools like Glade.
Since this need is hardly unique, in all probability, somebody must have implemented a solution—and, indeed, they have. The features module ( http://drupal.org/project/ features) is one such solution. statistics at http://drupal.org/project/usage.
I agree with the following comment in http://codekarate. com/blog/top-ten-best-drupal-7-contrib-modules : “If you aim to become a serious Drupal developer, you can't live without the features module. You may think of a feature as a use case. Or you may want to group all changes you made to a Drupal site that implement some user need.” But what does that mean? Your new requirement may be to add new vocabulary in the taxonomy module. The next step would be that you may require additional content types, which may use the additional vocabulary you hDYH GHfinHG. )LnDOOy, WhLs FonWHnW nHHGs Wo bH YLHwHG—IoU whLFh you PDy nHHG Wo GHfinH FusWoP YLHws. SubsHTuHnWOy, you wLOO nHHG Wo GHfinH PHnu OLnks, SHUPLssLons, HWF.
After you have added the needed functionality, you are ready to GHfinH D nHw IHDWuUH. GLYH LW D suLWDbOH nDPH, DnG HGLW FoPSonHnWs to add to this feature. It is remarkably simple. You will need to add the strongarm module in order to export the vocabulary.
When all the components have been added to the feature, export it as a tar fiOH, whLFh FDn WhHn bH GHSOoyHG on Dny oWhHU sysWHP. You may want to go through a tutorial to understand the steps—for example, http://www.ostraining.com/blog/drupal/features/.
If you make changes to any of the components, or add components to your features, you can re-export the revised feature, and deploy the updated version on the other systems. The content of the tar fiOH FDn bH DGGHG Wo D UHSosLWoUy OLkH GLW, and you have version control for the feature. If every capability of your site is part of some feature, your entire site is managed by version control. The code for the site is now in the repository and distinct from the content.
You can choose to apply (or ignore) the advice and methodologies of software engineering while developing Drupal 7 projects as well—but you won't be able to say that it can't be done!