Hugo, thanks for the detailed answer, which I'll take the time to analyse
in-depth ASAP.
Indeed, I can envision a day, maybe coming sooner than later, where we'd
like to use cloud services for some clients. Especially those who could
predict activity "peaks" due to their business plans, marketings, etc.
That's why I'm balancing the idea of jumping in something like pallet now,
when we're still not in the rush, or postpone it until the real problem, in
its real shape, occurs.
Cheers,
--
Laurent
2011/2/24 Hugo Duncan <duncan.h...@gmail.com>
> On Thu, 24 Feb 2011 06:29:13 -0500, Laurent PETIT <laurent.pe...@gmail.com>
> wrote:
>
> * deliver to pre-production:
>> * input = git commit hash, maven version of some "tooling" artifacts
>> which are java artifacts, invoked via an mvn java execute target once the
>> right git revision has been checked out
>> * output = publish the "app state" (created locally from the derived git
>> content) to a directory in the server, run a shell script on the server
>> which finishes the install, and, if everything went well, tag the commit,
>> and push the tag to the reference repo from which the content had been
>> initially pulled from
>>
>
> Would trying to use pallet or crane seem overkill ?
>>
>
> Laurent,
>
> Pallet would certainly be capable of automating the workflow you describe.
> From what you describe a shell script invoked by an ssh command could
> probably do the job too. In pallet it might look something like this
> (unchecked):
>
> (def release-dir "/usr/local/myapp")
>
> (defn push-preproduction*
> "Crate function to publish a specific commit"
> [request tag version artifacts]
> (exec-script/exec-checked-script
> request
> (format "Checkout version %s" version) ; message for logging, etc
> (cd src)
> (git checkout ~version)
> (mvn exec:java something ~@artifacts)
> (cp app-state ~release-dir)
> (finish-install)
> (git tag ~tag)
> (git push --tags)))
>
> (def push-production
> "Crate function to extract data from the environment,
> and publish it"
> [request]
> (push-preproduction*
> request
> (environment/get-for request [:userdata :tag])
> (environment/get-for request [:userdata :version])
> (environment/get-for request [:userdata :artifacts])
>
> ;; define phases on a "Server" group, linking the
> ;; publish phase to the push-production crate function
> (def server (make-node "server" {}
> :publish push-preproduction))
>
> ;; Function to publish a specific version. Uses the node definitions
> ;; from config.clj
> (def publish
> [request tag version & artifacts]
> (let [service (compute/compute-service-from-config-file :nl)]
> (core/lift server
> :phase publish
> :compute service
> :environment {:userdata {:tag tag
> :version version
> :artifacts artifacts}})
>
> Set up ~/.pallet/config.clj, specifying details of the existing machine,
> and that it should be in the "server" group
>
> (defpallet
> :providers
> {:nl {:provider "node-list"
> :node-list [["server" "server" "192.168.2.37"
> :ubuntu :os-version "10.04"]]
> :environment {:user {:username "user" :no-sudo true}}}})
>
> and invoked via
>
> (publish "tag" "commitish" "artifact1" "artifact2")
>
>
> Whether pallet is overkill or not, I think, is dependent on whether you
> think your requirements will grow. Using this as an exercise to learn
> pallet would be time well spent if you think you will want to automate more
> in the future.
>
> But, I'm biased.
>
> --
> Hugo Duncan
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
