The basics
dCycle defines a technique for developing website features and configuration in a dev-stage-production workflow.
dCycle is a work in progress. If you want to help improve it, please see the contact page.
dCycle does not define a method for content staging.
dCycle relies on centralized git repositories, outside of any Drupal site, to store the modules, libraries and themes directories under version control.
Developers and themers are expected to download the modules, libraries and themes directories to their personal development space, then use the steps in the README.txt file, to recreate a working copy of the website for development.
The dev site is used to test features and how they work together, using dummy content (for example generated using devel_generate, part of the devel module. The dev site is generally not considered stable; and the client will generally not create content on the dev site. The dev site is where automated tests are run, if you have them in your features.
The staging site is considered stable, and that's where stakeholders can play around with different features, add content, tests the limits of the system.
The production site is the live site where actual content is entered.
In addition to the dev, staging and production sites, it is considered good practice for each developer and themer to have his or her own version of the site, which is created by following instructions in sites/*/modules/README.txt.
Developers and themers can use devel_generate to create dummy content on their personal sites for theming and creating new features.
When a developer or themer is done working on his or her local development site, changes to the database are moved to code, either via the features module (in the case of views for example), or manually documented in sites/*/modules/README.txt, the idea being that new clones of the site, sans content, can be created by creating a new drupal site, pulling the themes, libraries and modules git repos, and then following the instructions in sites/*/modules/README.txt.
dCycle relies on all features and configuration information being moved from the database into code during development on a local development site, the code then being deployed via git to different platforms (dev, stage, prod), then the features and configuration being transferred to the target site's database. Here's how it's done:
- All instances of the site will have features, strongarm, and possibly other features-related modules such as context.
- Developers working on a local development instance of their site will use features, context and strongarm to move such things as block positions, views, content types, variable settings from the database to the code.
- Some configurations and features are not exportable to code via the features module. For these, the steps to obtain the desired outcome will be document in sites/default/modules/README.txt or sites/example.com/modules/README.txt.
- Code is then pushed back to the repos via git
- The dev, stage and production sites will then, in turn, pull the latest version of the code from the git repos
- Features will be reverted on each of these sites. The act of reverting a feature synchronizes the database with the code.
- The administrator, or person moving new versions of the code to the development, staging or production site, will make sure to follow any updated steps in the sites/*/modules/README.txt document..
- Using this technique, the database is never cloned.
About the name
The features module allows much configuration and features to be moved to code, making code reuse easier. dCycle aims to make it easier to develop Drupal sites in a cyclical fashion: Use existing features to build a new site, create new features while building your site, reuse these new features for your next site.
Comments
ybabel (not verified)
Mon, 04/16/2012 - 18:31
Permalink
FAQ ?
Hello,
I just discovered your workflow a few minutes ago. Please forgive if my questions are dumbs.
Are they any prerequisites ? (does it work for D6,D7 ? what about D8 ?) - any tools used ? aegir ? redmine, etc... seems to be used, is there a list somewhere of all the tools ? (not every projet use these tools)
What kind of site can we stage with your workflow ? is there any limitations of any kind ? (beside the features own limitations). Does it work on an already in production site or only new sites ? does it work with multilingual, OG, Domain and other "tricky" modules ?
What is the work overhead of using your workflow ? does it means 1.5X times more work ? 1.3X ? 2X ? any kind of evealuation ? how does it scale on large projects ?
How does it compare with other solution ? what is the difference between your solution and other solutions ?
alberto56
Tue, 04/17/2012 - 14:24
Permalink
Hi and thanks for your
Hi and thanks for your interest (and I don't believe in dumb questions!),
In general D6 has more components which use incremental IDs (as opposed to machine names) which can't really be exported. For example D6 uses incremental IDs for text formats, so for example a view which specifically uses a custom text format in D6 will behave unpredictably. D7 has less of these problems because it uses less incremental IDs for configuration. That being said, I have used dCycle on several D6 projects and it works fine. (Every indication is that D8 will be even better).
About the tools, good question: you can easily use dCycle without Aegir, but doing serious development and deployment without some sort of platform management tool is not recommended. Pantheon might be a good choice too but I have never used it with a real-world project (Pantheon works much like Aegir, but Pantheon is a service, and Aegir is an open-souce project). As for Redmine, you need some sort of system to manage git repos, Github works fine also (it also has an issue management system).
Every project has its limitations, but dCycle requires that the limitations be documented in modules/README.txt, so for sites with limitations and tricky modules, all you need to do is document the step-by-step procedures in README.txt for those aspects which can't be exported automatically.
dCycle scales well -- I am using it now on a very large project with a client in the municipal government. I'd say it takes about twice as long to develop a site this way, but over the life cycle of the site, I have personally found that it actually reduces support and maintenance time (which is why I use it!)
I guess there must be other such solutions floating around -- I know most developers use such solutions -- but I haven't found any that are actually documented. But as long as you have some sort of documented workflow which everyone in your team abides by, great!
Add new comment