Packaging & Deployment

This group serves as a central point to allow for the coordination and informal discussions amongst the developers of several modules (patterns, spaces/context, features, deployment, install profiles, etc.) that have similar and/or complementary functionality, allowing us to reduce the duplicated code bases and more easy leverage each other's solutions.

The goal of this group is to put together a set of 'best practices', that allow for the easy integration of all these modules, and the education of these best practices to the contributed module developers, so that the resulting system can provide a solid platform for resolving the packing and deployment problems we are faced with.

adrian's picture

Tell Us How Drush Has Made Your Life Easier and Get a Free Shirt

To celebrate the launch of Drush 2.0, we’re handing out several I <3 Drush t-shirts.

If you want a shirt, what you need to do is make a screencast or blog post about how Drush has made your life easier. Show or explain how you used to do something manually, and how it’s much quicker and simpler with Drush. Once you’ve posted about Drush, tweet about it with the #drushrush tag, and we’ll select the top three posts and those authors will receive a t-shirts in the mail.

So start posting and happy drush’ing. Oh yeah, you can also buy the shirt over here but what fun is that.

DamienMcKenna's picture

Posted some details on building installation profiles

For anyone who attended the Florida May meeting where I presented a case study on my work for ScubaDiving.com, which focused a lot on installation profiles.. well I finally posted some details on my blog on how I built it, along with some related details:

http://www.mc-kenna.com/drupal/2009/06/building-drupal-installation-prof...

Please post comments on my blog if you have any feedback, in the interests of keeping the discussion centralized.

Chris Charlton's picture

Do you test new modules before uploading them to your live site?

I test every module I download before installing it on my live site(s).
60% (92 votes)
I have tested some modules before deploying.
25% (39 votes)
I have not tested any modules before uploading them to my site.
5% (7 votes)
I have not tested any modules, but really should.
8% (12 votes)
I code every module I use and never, ever need to test my own code.
3% (4 votes)
Total votes: 154
adrian's picture

Aegir 0.2 release candidate 1 released.


We're proud to announce the first release candidate of the 0.2 release of the Aegir hosting system for Drupal.

Ægir is a set of contributed modules for Drupal that aims to solve the problem of managing a large number of Drupal sites. It does this by providing you with a simple Drupal based hosting front end for your entire network of sites. To deploy a new site you simply have to create a new Site node. To backup or upgrade sites, you simply manage your site nodes as you would any other node.

This release is the first release candidate of our 0.2 development cycle, which has been focused on complete support for running multiple concurrent Drupal releases, and managing upgrades of sites between Drupal releases. This release has been focussed on improving some our experimental multi-client functionality, as well as fixing bugs for our final release.

Aegir is in code freeze, and only bug fixes and usability improvements will be allowed in. The final release of Aegir will occur shortly after the 2.0 final release of Drush, and we will only be making changes to Aegir to maintain compatibility with Drush upstream.

Read more
anarcat's picture

Aegir 0.2 beta 1 released.


We're proud to announce the first beta of the 0.2 release of the Aegir hosting system for Drupal.

Ægir is a set of contributed modules for Drupal that aims to solve the problem of managing a large number of Drupal sites. It does this by providing you with a simple Drupal based hosting front end for your entire network of sites. To deploy a new site you simply have to create a new Site node. To backup or upgrade sites, you simply manage your site nodes as you would any other node.

This release is the first beta release of our 0.2 development cycle, which has been focused on complete support for running multiple concurrent Drupal releases, and managing upgrades of sites between Drupal releases. This release has also primarily been focussed on fixing bugs and polishing the final release of the 0.2 release.

Read more
adrian's picture

Aegir 0.2 ALPHA 1 released.

We're proud to announce the first alpha of the 0.2 release of the Aegir hosting system for Drupal.

Ægir is a set of contributed modules for Drupal that aims to solve the problem of managing a large number of Drupal sites. It does this by providing you with a simple Drupal based hosting front end for your entire network of sites. To deploy a new site you simply have to create a new Site node. To backup or upgrade sites, you simply manage your site nodes as you would any other node.

This release is the first alpha release of our 0.2 development cycle, which has been focused on complete support for running multiple concurrent Drupal releases, and managing upgrades of sites between Drupal releases. This release has also primarily been focussed on improving and simplifying the back end system, by incorporating a lot of our custom API's upstream into the Drush 2.x project.

Update: Check out this screencast for a quick walkthrough of the features available in this release.

Read more
adrian's picture

Drupal 'ports' collection

What is it?

My recent work on Aegir has been very deeply oriented with Drupal package management and dependency checking.

From the perspective I have been working from (unix command line scripts), the currently existing functionality of the update module is simply not useful.
I am in need of an easily mirrorable meta-info repository of all the drupal projects, and all the drupal modules. I need to be able to figure out dependencies

Read more
dmitrig01's picture

Exportables module

Yesterday I released the exportables module, which allows views-style exportables on objects which normally can't be exported (because of a lack of machine readable name). Currently, I've implemented taxonomy vocabularies, but more are planned -- add your own ideas in the comments for what I should make exportable next. Vocabularies are implemented using this code -- http://pastie.textmate.org/437640. Currently, there is no features module integration, however I'm working on that.

kvantomme's picture

mentors for a patterns like module builder

There is a GSoC proposal at http://groups.drupal.org/node/20917 that you should check out.

In short it's a patterns-like module that can be used to build modules. It could help a lot to speed up the development of little helper modules that projects often need (e.g. to add a little extra functionality, but that are not contribution worthy).

Tamas, has been a trainee for almost a year now at our company and I'll be his "local mentor" for GSoC.

He would still need co-mentors with relevant technical background. Anybody interested?

mitchell's picture

Package Management

Note: My proposal has evolved to include a detailed schedule, glossary, and long brief about the reasons why my methodology is at least different, if not better than the existing ones. I have moved the content from this single page to the Package Management project page. The project home page links to the SoC Proposal with the schedule.

Old Titles for this project ordered by earliest (from these you can see 3 major aspects of the project):
Automated Drupal Software Appliance Builder

Read more
adrian's picture

A look at my Data API proposal from Drupalcon Brussels 06

All this import/export malarky is actually part of a problem I identified many years ago, while writing FAPI.

FAPI in it's current state was always meant to be the first phase in a much larger project to fix a lot of the inherent design problems we have been bumping heads against now.

If the code looks 'non-drupal like' to you, keep in mind when this presentation was done, FAPI itself was new, and such sweeping changes still had an opportunity of being taken seriously. Unfortunately I suffered from burnout shortly afterwards, and extracted myself from doing serious core development.

FAPI3 - AKA Data API presentation

Read below for some comments on this :

Read more

Action Plan

This is a wiki page to figure out the immediate plan of action.

Off the top of my head :

  1. Identify existing modules with overlap.
  2. Create a list with all existing object types
  3. Identify which can be imported and exported by the existing modules.
  4. Generate a matrix of modules versus object types, and also the mechanism of import/export (ie: drupal_execute, nodeapi/userapi, own crud functions, module's own api).
  5. Take the best implementation we have for each object and move them to a central API module.
Read more
moonray's picture

Import/Export API (Input/Output API)

Based on the discussions we had at DrupalCon, I've written up the beginnings of an API with a standardized set of hooks and some functions.

The details of how, for instance, the block module would save an object to disc might start through using the not-so-desirable form API, due to lack of another option. In the future, however, this could be changed using a more optimal method.

Also included is a generalized function to fetch set of default objects that are embedded in PHP (like views module or context module implement).

Discussion is encouraged. :-)

io.module

Read more
yhahn's picture

Features module quick demo

Jeff Miccolis and I spent some time last week pulling together a proof of concept -- we're calling it the "features" module. Jeff writes:

/**
* @file
* Module file for the features module, which enables the capture and
* management of features in Drupal. A feature is a collection of Drupal
* entities which taken together statisfy a certain use-case.
*/

Here is a quick informal screencast of what this thing does from the UI perspective:

http://video.devseed.s3.amazonaws.com/features_mar13_2009_p1.swf
http://video.devseed.s3.amazonaws.com/features_mar13_2009_p2.swf

What will be of more interest probably to people in the group is the internals of the module. If you're interested, take a look at README.txt and API.txt, where I've documented some of the basic concepts for feature component and module dependency detection. The core concept behind features is that you can start from some starting point in Drupal and allow each derivative component to delegate export and dependency detection to its derivatives and so on.

Read more
bhuga-gdo's picture

Notes from BoF

I blogged my notes of our meeting, and here they are, cross-posted from http://bhuga.net/2009/03/importexport-bof-drupalcon-2009-dc

My food poisoning at DCDC (don't eat rare meat in DC!) abated just long enough for me to attend an excellent BoF towards the end of Friday at Drupalcon DC 2009. The goal was workable configuration management in Drupal, and in no particular order, attending were:

Read more
Subscribe with RSS Syndicate content

Packaging & Deployment

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: