Posted by dconnet on March 13, 2015 at 3:20pm
We are being advised by a section of our organization to establish the following practices and I would like your input and help.
All feature development should be banned
Modules in dev, alpha and beta status should be forbidden.
If any module is necessary in these states it should be a code branch.
Drupal sites should be maintained at least monthly with all modules with new releases being updated. I'm not talking about Core here, I'm talking about always keeping modules at the current version.
Do these guidelines reflect best practice? What advice and recommendations do you have?
Comments
All feature development
Not sure what that means. Don't write your own modules?
Forbidden is a strong word. They are to be avoided, for sure, but sometimes it is just fine.
Sure, sounds good.
You may want to respond faster if a critical security update is released. Depends on the site.
Additionally, if you must patch a module (also to be avoided), make sure there is a process and documentation around it. Dave Reid has released a snazy Drush command to help with that. https://bitbucket.org/davereid/drush-patchfile
All feature development
By "feature" do you mean new functionality? If so, what is the reasoning for this?
Can you clarify what you mean by "code branch"?
At Promet Source, we take the following approach:
This is quite strong. We adhere to the following: "Stable versions should be used wherever possible. Unstable versions should be used only when they contain critical fixes/functionality and have been thoroughly tested."
Is there a reason not to include core? Updating monthly seems reasonable with the exception of security updates, which should be performed ASAP.
The above comments are good.
The above comments are good. I'm going to expand a bit here.
This seems pretty extreme. Using the Features module to codify configuration is a pretty standard practice for many Drupal shops. However, you should only use feature modules that come from trusted sources. I could see a policy of not using Feature modules unless they come with the distribution you are using or were developed in house. Downloading code of any type from un-trusted sources can be a risk.
Sometimes, you may need to use a version of a module that is not in release. The only real difference is that release versions of modules are reported on by the Drupal security team. You should prefer release modules, but if you need a non-release version you will just have to keep a closer eye on it and evaluate the code yourselves.
If you need the code in production, it should all be in one branch. If you are in a development environment, yes, please evaluate it in a separate feature branch. Everything should be first introduced in a branch and tested before being merged into the branch that is on production. I suggest your team adopt a Git workflow. Our office uses Git Flow.
Core and contrib should be treated the same in terms of "maintenance". It would be nice to have a periodic review to see if there have been any non-security related enhancements or bug-fixes. That process may allow you to move to using a release version of a module sooner. However, for security related updates and maintenance, I suggest you have a process for implementing them as soon as you find out about them. Subscribe to the Security announcements list and/or subscribe to their RSS feeds. They usually announce security updates to both core and contrib on Wednesday afternoons, though if a serious enough vulnerability gets discovered/patched it may be at any time.
Get Drush across all of your environments (dev/stage/prod) if you haven't already. It makes working with sites a lot easier, plus it can be used in scripts for deployment, backup, and copying/sanitizing sites for development. Feel free to post again if you have other questions, come to meetings (sorry our last one was canceled, a few of the organizers were [and still are] under the weather), and attend professional development opportunities such as camps and DrupalCon.