Hi all,

I'm thinking of using Drupal for creating a (somewhat ambitious..) web project manager, which goal would be to manage a list of different web project, implementing features usefull for a web developement environment:

- file operations : synchronization between local, test and live server, backuping config
- database operations : syncro + remote backuping config
- bug tracker (basically for now, create a new project in the bug tracker when a new project is created in the tool)
- htaccess management
- svn management
- etc..

So it's a bit like plesk, but more oriented toward developement tasks than server config. with support for server syncronization, and a possibility to add functionality in automatizing repetitive tasks (wrapped in drupal modules). While this is not typical drupal content (no stories, no forums, no comments), I would benefit, among other things, of drupal's hook system. Here's my plan, on a technical level. (please keep in mind Drupal is new to me)

- put each group of behaviour in a different module.
i.e : file operations, DB operations, bug tracker stuff, backup config stuff, and so on.
- define new hooks so that my modules can emit signals and/or collect information from other modules
i.e : suppose the htaccess management module wants to give a chance to all other module to add something in the htaccess before it is written
- make a node type for projects (and so a project module )
- make "buddy" database tables for modules that need to save info related to a project. A few joins between all those would select all information related to a project.

off the top of my head, some questions :

- Does such a tool exists already ?

- Do you think Drupal fits the need for developing such a tool?

- I know a module can add a table to complement nodes with extra info, but can multiple modules do this to the same node type?

- I see classes are rarely used throughout the sources. Are classes somewhat blasphematory in Drupal's code ? What is the general guideline ? Would a module be accepted if the design uses classes a lot (obviously respecting the hook nomenclature)?

- What are the ways to give it to the community . The problem I see here is that, to me, it would suit more as drupal distribution (?) than a few modules, because they would be so mutually dependent.

- I'm still looking for good docs explaining how work taxonomy/vocabularies, so if someone a a good pointer, please paste it

Cheers,
Julien

Comments

boris mann’s picture

It's an interesting model....do you want to drive static sites, or do you want to drive lots of Drupal powered sites?

Such a tool does not exist...you might want to actually remove some features, and just actually start with project management (e.g. kind of a better Basecamp). The server to server operations are going to be very difficult. Depends on where your interests lie.

Drupal is probably as good a fit as any framework. Depends on how you might potentially have to integrate with other services.

Yes, multiple modules can hold extra node-related information. This is pretty much how most information flows work in Drupal -- e.g. both event.module and location.module can hold information about a node.

You are free to use classes in your contrib module, but such code will not be accepted into any core modules.

To give it to the community, I would suggest focusing on some core functionality and starting out with contributing individual modules. The next step can be working on a distribution. Distributions will be much easier in the 4.7 timeframe, since they can be built using the install system.

See http://www.drupaldocs.org for API reference docs. Not sure what else you need on taxonomy/vocabs. Basically, it's a way to organize nodes for various purposes. Image and Forum modules are examples of two modules that use the taxonomy/vocab framework to organize info, but don't require people to set them up separately.

Hope that helps.

jkeable’s picture

Thanks for the relevent reply. Now that I see that my post has not fallen into the abyss of the forgotten internet, I can be more descriptive.

For me, the interesting aspect is the automation of repetitive tasks , over the project management benefits. The latter would come as a bonus through the use of other contributed drupal modules (wiki, etc.. btw, any bugtracker yet ?)

The project should drive static, drupal, or custom sites. For example, a (conditionnal) Drupal module could handle operations specific to a drupal project. i.e : if a drupal project needs to do specific things on some events, then hooks would handle that . i.e :

1- the database password is changed for the local server : a hook gives a chance to all modules to perform some tasks, so the drupal modules can update the settings file on the local server.
2- a new project is created, drupal modules handles the nip&tuck operations specific to a new drupal project

I still have to clarify the dependencies between modules and the hooks that would need to be implemented by simulating typical use cases.

So the basic Idea :

Project module: extends a node to include general info about a project :

- description
- state (production, archive, etc)
- serial number for administration
- etc..

this module has a "has-many" relation to servers, which would be another class/module having the following attributes :

(Abstract) Server Module :
- path of the project
- database info (host, user, passwd, database)
- etc..

By inheriting from the server class, specialized classes could be implemented for each server type. i.e :

Specialized server modules :
- our remote server which is based on plesk, Fedora Core
- our local server, Debian

About managing inter-server operations, I would do it this way :

each of these server classes would have a corresponding "ambassador" (there sure is a name for that design pattern but I forgot it) to do the job on the server, by implementing some interface, thru XMLRPC calls. E.g.:

- create subdomains :
- remote server : use plesk command line tool
- local server: custom scripts

- file syncronization : one of these ambassadors could launch a rsync command on the other server.

So, to sum up :

- Projects modules would make the basic node

Various modules could complement a node (as Localization or Event modules do) : 

- any number of server modules. Most commonly  3 : local, remote-demo and remote-live. (Well actually, maybe I should hardcode that. It would probably simplify things.)
- other specialized modules that are activated for a project depending on its type, some of them being mutually exclusive (drupal, wordpress) :
  - drupal
  - wordpress
  - our own php framework
  - bugtracking
  - wiki

If someone has an idea, or sees a pitfall , you're most welcome to reply !

btw, I will be doing this in a corporative context, so it should not turn out as vaporware.

Julien
------

If one's interested, here's a geek side dish, I lost this post hitting the back button. I managed to find it back by dumping and searching in the browser process memory with :

ps aux | grep firefox-bin
(get process number)
gdb firefox-bin 7258
cat /proc/7258/maps
(get start/end adress of heap segment)
[gdb]> dump memory somefile.dat 0x(begin adress) 0x(end adress)
(open somefile.dat and search for post text)
(find post)
(laugh at how you evade your bad karma)

boris mann’s picture

I just looked at your profile page...you're a Koumbit-er. I spent a bunch of time talking to Omar about this when he was here in Vancouver. Our mass hosting platform -- which is driven from a Drupal web interface but runs on a Python daemon -- does a lot of this already.

I sent Omar a short note the other day...we can have a conference call when I get back from Europe in a couple of days to discuss more.

Basically, as I see it, what you are describing is the account management interface -- the series of hooks etc.

We've talked a bit about various approaches to remote server management. Like agents which drive local tasks, or other approaches to having centralized management for remote boxes.

The main thing is (for the Drupal installs at least), they aren't standalone sites -- they are mass hosted. Being able to roll out standalone sites *as well* is interesting and bears some more thinking about.

omar’s picture

... although Julien also has a day job :-)

Anyway, Julien... I think that you will have to watch out not to reproduce some of the elements that are already available in Drupal. Moreover, while I know that you are skilled enough to accomplish anything you set your mind to, I'd highly encourage you byte off one piece at a time. I think that you will get a lot more accomplished this way.

Overall, if you want to contribute to (and get the most out of) the community, you should start by tackling the issues that are most closely related to those already being identified/addressed by the community.

For example, while there is a project/bug tracker in Drupal, there's a lot of grumbling going on about its limitations. Similarly, from my understanding cvs is also being pushed to the limits.

No matter what though, IMHO, "hosting-shop-tool" projects are going to be more and more prevalent. We should get together with Anarcat to work out some of the details and see what we could do in collaboration with Bryght and Civispacelabs.

We should get together face-to-face with and others .

boris mann’s picture

There is also casetracker, which is meant to handle projects, that you might want to look at.

juliangb’s picture