From Fedora Project Wiki

 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''''This is a draft.'''''
{{admon/important|This is a draft.|}}


----
----


==What is Features?==
== What is the Features module? ==


We are using [http://drupal.org/project/features Features module]. We can build custom features with this module because "no need to programming, just click-click and done". We can organize the each part of our Insight page into one or more feature like a custom module. So I would suggest that, create a few new features like "Super Event Calendar".
The [http://drupal.org/project/features 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 to do this? What is a workflow?==
== How does this work? ==


That is a good question. We have to figure it out how to do this easily. I suggest that we put our features into a git repository like Insight repository, which contains our features, for example "Super Event Calendar", "Awesome Podcast System".
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.


We have to complete this section, have to speak about this. --[[User:Asrob|Asrob]] 18:01, 11 May 2011 (UTC)
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.


==How to use Features?==
== General usage ==


Need to review this! --[[User:Asrob|Asrob]] 19:17, 11 May 2011 (UTC)
To use Features in general:
# Download the Features module from http://drupal.org/project/features
# Enable the module on http://example-domain/admin/build/modules page.
# Manage the features on http://example-domain/admin/build/features page.
# Create a custom feature on http://example-domain/admin/build/features/create page.


1. Download the Features module from http://drupal.org/project/features
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''.


2. Enable the module on http://example-domain/admin/build/modules page.
After this process, you can upload your custom feature on the server into the ''sites/all/modules'' directory.


3. Manage the features on http://example-domain/admin/build/features page.
To use a custom feature you've created, visit the Features page, select the checkbox for that selected custom feature, and select ''Save settings''.


4. Create a custom feature on http://example-domain/admin/build/features/create page.
== How Insight uses Features ==


If you want to create a custom super feature, you have to click _create feature_ link at the top on the create feature page, see step 4.
=== Git branching and merging ===


Fill those requirements(Name, Description, Version) as you like it, then select those settings at the _Edit components_ part. If you have done with this, just click the _Download feature_ button.  
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.


After this process, just upload your custom feature on the server into the "sites/all/modules" directory.
'''However, developers are asked not to push directly to ''either'' of these branches.'''


When you created a custom feature and you would like to use it, then you have to go on Features page, see step 3.
Instead, developers work on their feature on a separate branch of their own.  Recommended naming is something like ''<username>-<feature-description>''.  An example might be ''mqjones-social-networking''.  Push these branches as is, to the repository (making a new remote branch as needed).  This way, we can work on multiple features at once, and developers can share or collaborate as needed without leaving any of our live sites in an uncertain state.


If you want to enable a custom feature, you have to click a checkbox of the selected custom feature then click _save settings_ button.
''When a feature is complete and ready for developer testing'', merge that branch to the ''devel'' branch.  Reference all tickets addressed with this feature in the commit log (the text ''ticket 423'' is fine).  Individual references in several commits is fine too.  Remember the purpose is to make your work very clear to someone looking at it later when you're not around to explain it.
 
''Once you complete the merge'', resolving any problems, tag the resulting commit 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]]'', merge the ''devel'' branch into the ''master'' branch.  The production site will automatically pull the changes from ''master''.
 
=== Procedure ===
 
==== Initial work ====
<ol><li>Clone the repo:
<pre>git clone ssh://git.fedorahosted.org/git/fedora-insight-features.git</pre></li>
 
<li>Change the directory:
<pre>cd fedora-insight-features</pre></li>
 
<li>Make a new branch for your work:
<pre>git checkout -b mqjones-social-networking</pre>
{{admon/note | Changes | If you're changing an existing feature module, you can use the existing directory; you don't need to make a new one. This makes merging easier.}}</li>
 
<li>Make a new directory:
<pre>mkdir social_networking</pre></li>
 
<li>Copy your feature files:
<pre>cp path/to/my/feature/* ./social_networking/</pre></li>
 
<li>Add the directory of feature:
<pre>git add social_networking/</pre></li>
 
<li>Commit your changes:
<pre>git commit -a -m "Added social networking feature (ticket 42)"</pre></li>
 
{{admon/note | Repeat feature work and commits as often as needed.}}
 
<li>Push your changes:
<pre>git push ssh://git.fedorahosted.org/git/fedora-insight-features.git/ mqjones-social-networking</pre>
 
{{admon/warning | Use your own branch for pushing! | Features under development are not pushed directly to ''devel'' or ''master'' without being tested and approved by the team.}}</li>
</ol>
 
==== Merging to ''devel'' ====
 
{{admon/note | Only merge completed features | Your feature will go live on the development site. Don't panic if there's a bug; that's why we have a development site. But do wait until you're finished.}}
 
<ol>
<li>Make sure you are on the ''devel'' branch, and that you have the latest content:
<pre>git checkout devel
git pull</pre></li>
 
<li>Merge the changes:
<pre>git merge mqjones-social-networking</pre>
Resolve conflicts, if any.</li>
 
<li>Tag the new head according to the feature version you set and the "-test" suffix:
<pre>git tag social-networking-0.2-test</pre></li>
 
<li>Push the results:
<pre>git push --tags</pre></li>
</ol>
 
==== Merging to ''master'' ====
 
{{admon/warning | Only merge tested features | Your feature will go live on the production site. Don't do this until the team approves the change.}}
 
<ol>
<li>Make sure you are on the ''master'' branch, and that you have the latest content:
<pre>git checkout master
git pull</pre></li>
 
<li>Merge the changes:
<pre>git merge devel</pre>
There shouldn't be any conflicts, but if there are you might want to let someone know before you go any further.</li>
 
<li>Tag the new head according to the feature version you set:
<pre>git tag social-networking-0.2</pre></li>
 
<li>Push the results:
<pre>git push --tags</pre></li>
</ol>

Latest revision as of 19:21, 29 July 2011

Important.png
This is a draft.

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 work on their feature on a separate branch of their own. Recommended naming is something like <username>-<feature-description>. An example might be mqjones-social-networking. Push these branches as is, to the repository (making a new remote branch as needed). This way, we can work on multiple features at once, and developers can share or collaborate as needed without leaving any of our live sites in an uncertain state.

When a feature is complete and ready for developer testing, merge that branch to the devel branch. Reference all tickets addressed with this feature in the commit log (the text ticket 423 is fine). Individual references in several commits is fine too. Remember the purpose is to make your work very clear to someone looking at it later when you're not around to explain it.

Once you complete the merge, resolving any problems, tag the resulting commit 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, merge the devel branch into the master branch. The production site will automatically pull the changes from master.

Procedure

Initial work

  1. Clone the repo:
    git clone ssh://git.fedorahosted.org/git/fedora-insight-features.git
  2. Change the directory:
    cd fedora-insight-features
  3. Make a new branch for your work:
    git checkout -b mqjones-social-networking
    Note.png
    Changes
    If you're changing an existing feature module, you can use the existing directory; you don't need to make a new one. This makes merging easier.
  4. Make a new directory:
    mkdir social_networking
  5. Copy your feature files:
    cp path/to/my/feature/* ./social_networking/
  6. Add the directory of feature:
    git add social_networking/
  7. Commit your changes:
    git commit -a -m "Added social networking feature (ticket 42)"
  8. Note.png
    Repeat feature work and commits as often as needed.
  9. Push your changes:
    git push ssh://git.fedorahosted.org/git/fedora-insight-features.git/ mqjones-social-networking
    Warning.png
    Use your own branch for pushing!
    Features under development are not pushed directly to devel or master without being tested and approved by the team.

Merging to devel

Note.png
Only merge completed features
Your feature will go live on the development site. Don't panic if there's a bug; that's why we have a development site. But do wait until you're finished.
  1. Make sure you are on the devel branch, and that you have the latest content:
    git checkout devel
    git pull
  2. Merge the changes:
    git merge mqjones-social-networking
    Resolve conflicts, if any.
  3. Tag the new head according to the feature version you set and the "-test" suffix:
    git tag social-networking-0.2-test
  4. Push the results:
    git push --tags

Merging to master

Warning.png
Only merge tested features
Your feature will go live on the production site. Don't do this until the team approves the change.
  1. Make sure you are on the master branch, and that you have the latest content:
    git checkout master
    git pull
  2. Merge the changes:
    git merge devel
    There shouldn't be any conflicts, but if there are you might want to let someone know before you go any further.
  3. Tag the new head according to the feature version you set:
    git tag social-networking-0.2
  4. Push the results:
    git push --tags