Insight development using Features module

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Add marker)
(Proposed git branch/merge process)
Line 31: Line 31:
 
=== Git branching and merging ===
 
=== Git branching and merging ===
  
'''COMING SOON'''
+
We use two official git branches for Feature management for [[Insight]]. The ''devel'' branch is used to power our development site, and the ''master'' branch is used for the more official staging and production sites. 
 +
 
 +
'''However, developers are asked not to push directly to ''either'' of these branches.'''
 +
 
 +
Instead, developers are asked to develop their feature on a separate branch of their own.  Recommended naming is something like ''<username>-<feature-description>''.  An example might be ''mqjones-social-networking''.  These branches should be pushed as is to the repository (making a new remote branch as needed).
 +
 
 +
When a feature is truly done, and ready for developer testing, that branch should be merged to the ''devel'' branch.  Once the merge is complete (including any problems resolved), the resulting commit should be tagged with the feature name and version, such as ''social-networking-0.2''.  The development site will pull any changes within an hour, or one of the admins on the team can manually pull if needed.  Following testing, once the team has [[How to develop for Insight | approved the change]], the ''devel'' branch is merged into the ''master'' branch, from which the production site will automatically pull the changes.
  
 
=== Procedure ===
 
=== Procedure ===

Revision as of 00:49, 18 May 2011

Important.png
This is a draft.

Contents

What is the Features module?

The Features module allows us to build custom features that don't involve programming by hand. We can organize the each part of our Insight page into one or more feature like a custom module. For instance, we could create a new feature like a "Super Event Calendar."

How does this work?

A Feature itself (with a capital "F") is constructed out of exportables created by existing modules that the Features module understands (either intrinsically or because those modules support the Features API). This sounds a lot more complicated than it is.

For example, imagine that you want to create a capability on the Drupal 6 server that involves a few custom Views, and perhaps some custom CCK fields. You can gather these customizations (let's call them "exportables" here) together and give that collection a name using the Features module. The Features module creates a set of custom code, which it can then export as a module. The code can then be managed through a SCM repository, allowing for change management.

General usage

To use Features in general:

  1. Download the Features module from http://drupal.org/project/features
  2. Enable the module on http://example-domain/admin/build/modules page.
  3. Manage the features on http://example-domain/admin/build/features page.
  4. Create a custom feature on http://example-domain/admin/build/features/create page.

To create a custom super feature, click Create feature at the top on the create feature page. Fill out the requirements (Name, Description, Version) as desired, then select settings in the Edit components section. When finished, select Download feature.

After this process, you can upload your custom feature on the server into the sites/all/modules directory.

To use a custom feature you've created, visit the Features page, select the checkbox for that selected custom feature, and select Save settings.

How Insight uses Features

Git branching and merging

We use two official git branches for Feature management for Insight. The devel branch is used to power our development site, and the master branch is used for the more official staging and production sites.

However, developers are asked not to push directly to either of these branches.

Instead, developers are asked to develop their feature on a separate branch of their own. Recommended naming is something like <username>-<feature-description>. An example might be mqjones-social-networking. These branches should be pushed as is to the repository (making a new remote branch as needed).

When a feature is truly done, and ready for developer testing, that branch should be merged to the devel branch. Once the merge is complete (including any problems resolved), the resulting commit should be tagged with the feature name and version, such as social-networking-0.2. The development site will pull any changes within an hour, or one of the admins on the team can manually pull if needed. Following testing, once the team has approved the change, the devel branch is merged into the master branch, from which the production site will automatically pull the changes.

Procedure

  1. Clone our Features repository
    git clone ssh://git.fedorahosted.org/git/fedora-insight-features.git
  2. Make a new branch for your work
    git checkout -b my-new-feature
  3. Change the directory
    cd fedora-insight-features
  4. Make a new directory
    mkdir my_awesome_feature
  5. Copy your feature files
    cp path/to/my/feature/* ./my_awesome_feature/
  6. Add the directory of feature
    git add my_awesome_feature/
  7. Commit your changes
    git commit -a -m "My awesome feature has been added"
  8. Push your changes
    git push ssh://git.fedorahosted.org/git/fedora-insight-features.git/ devel
    Note.png
    Use devel branch for pushing
    We use a different branch for the production status. Features under development are not pushed directly to that branch without being tested and approved by the team in some fashion.