That sounds like an efficient solution too. But for my project that's a bit too much, I guess.
2013/8/11 Nathan Brazil <n...@bitaxis.com> > I had a similar challenge. Here is a rough idea of what I did: > > I started with different kinds of deployables, such as config files, > shared libs, apps, etc. Each kind of deployable got its own class that > knows how to deploy that kind of deployable via a deploy() method. > > Then I created the concept of deployment groups. Each group would contain > a set of deployables. There was a core group containing deployables > applicable to all servers, another group that pertained only to subset A of > the severs, still another that pertained only to subset B, etc. > > Then I associated each role to a set of groups. > > So, when I would execute > > $ fab -R master deploy # OR > $ fab -H slave deploy > > > the task code would march through the groups for the role to form a set of > deployables, iterate through the set, and call the deploy() method on each > item for each server belonging to the role. > > Furthermore, if I were to run > > $ fab -H host1 deploy # OR > $ fab -H host2 deploy > > > the task code would figure out the role that host belonged to, and repeat > the above process to deploy just to that server. > > -- > > On Aug 10, 2013, at 8:09 PM, Jens Rantil <jens.ran...@gmail.com> wrote: > > Hi dAnjou, > > I see that noone has responded to you, so I'll give it a shot. It seems > like you posted three separate, but duplicate e-mails, to this group. Let's > hope all succeeding replies stick to this thread to keep things searchable > and browsable. One e-mail is enough in the future. ;-) > > There's multiple ways of doing what you want. Either way, I'd use > functions and not classes. I guess it's just a personal preference. Pick > and choose: > > 1. Setting up initial state in a task: Create one task that configures > your env variable with all information needed to execute further tasks. > This makes it possible to execute > > $ fab master deploy > ... > $ fab slaves deploy > ... > > This works especially well if deployment is fairly similar. > > 2. Use two "meta" tasks; ie. 'deploy_master' and 'deploy_slaves'. These > two tasks can set up env state and call the individual tasks (possibly > using `execute`[1]) needed to execute the individual steps of each > deployment. > > [1] > http://docs.fabfile.org/en/1.7/api/core/tasks.html?highlight=execute#fabric.tasks.execute > > Cheers, > Jens > > Sent from my iPhone 5S > > 9 aug 2013 kl. 18:00 skrev dAnjou <m...@danjou.de>: > > Hi, > > > (first post here) > > > I have two roles (lets call them master and slaves). They have a different > deployment setup but they share a particular set of configuration options. > Other options are different though. What is the best way in fabric to do > this kind of thing? All I can imagine is having a base config class and > then two subclasses that override or add certain options. > > > Thanks in advance. > > > dAnjou > > _______________________________________________ > > Fab-user mailing list > > Fab-user@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/fab-user > > _______________________________________________ > Fab-user mailing list > Fab-user@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fab-user > > >
_______________________________________________ Fab-user mailing list Fab-user@nongnu.org https://lists.nongnu.org/mailman/listinfo/fab-user
