Rationale behind deployment callbacks / hooks


#1

Hi chefs,

can somebody explain the rationale behind deployment callbacks, also called
deployment hooks [1]? More precisely, I understand their purpose quite well
(and use them myself), however I don’t understand why they should be stored
in the application code base instead of inside the cookbooks.
According to Scalarium documentation [2], it is an inherited Capistrano
behaviour, but that doesn’t answer the question of location AFAICT.

The reasons I’m asking are the following:

  • it’s a pain to maintain deployment code in two distinct repositories, and
  • I’m just curious :slight_smile:

Any pointers?

Cheers,
Loïc

[1]
http://wiki.opscode.com/display/chef/Deploy+Resource#DeployResource-InteractingwithYourInfrastructureDuringDeployment
[2]
http://support.scalarium.com/kb/deployment/how-can-i-use-deployment-callbacks


Loic ANTOINE-GOMBEAUD
IT contact & DevOps Engineer

Plinga GmbH | Saarbrücker Straße 20/21 | 10405 Berlin | Germany
E-Mail: loic.gombeaud@plinga.com | skype: loic.plinga
Cell: +49 (0) 160 922 86573

Geschäftsführer: Johannes Kreibohm, Florian Schmidt-Amelung
Eingetragen beim Amtsgericht Charlottenburg, HRB 119994


#2

On Thursday, January 24, 2013 at 6:42 AM, Loïc Antoine-Gombeaud wrote:

Hi chefs,

can somebody explain the rationale behind deployment callbacks, also called deployment hooks [1]? More precisely, I understand their purpose quite well (and use them myself), however I don’t understand why they should be stored in the application code base instead of inside the cookbooks.
According to Scalarium documentation [2], it is an inherited Capistrano behaviour, but that doesn’t answer the question of location AFAICT.

The reasons I’m asking are the following:

  • it’s a pain to maintain deployment code in two distinct repositories, and
  • I’m just curious :slight_smile:

The deploy resource is a port of an earlier project that provided Capistrano-style deployment for Chef, developed and used at Engine Yard, and the intention was to provide compatibility with that implementation. You can imagine that in an Engine Yard type scenario, you may be able to fill in all the parameters to the deploy resource from information you have in a database or with sane defaults for your environment, while allowing some custom functionality via hooks that live in the code repo.

If you don’t want to keep the callback code separate, you can just give blocks of Chef code to the callbacks instead of looking up the files.

Any pointers?

Cheers,
Loïc

[1] http://wiki.opscode.com/display/chef/Deploy+Resource#DeployResource-InteractingwithYourInfrastructureDuringDeployment
[2] http://support.scalarium.com/kb/deployment/how-can-i-use-deployment-callbacks


Daniel DeLeo


#3

That’s really interesting, thank you for your answer. I’m going to digress
here, but you’ve made me even more curious: is it common for open-source
projects to implement features that benefit one user / group of users’
requirements, but not necessarily all of them? How is that decision made:
is it a conscious, group-approved decision, or does it just “happen”?

I’m at the very beginning of my career and have never dabbled in
open-source before, I must say I’m quite impressed by what a community of
people scattered around the world can achieve, even knowing that there is
often a core of developers based in the same physical place.

What would be a good reference for getting to know those work mechanisms
better?

On Thu, Jan 24, 2013 at 5:09 PM, Daniel DeLeo dan@kallistec.com wrote:

On Thursday, January 24, 2013 at 6:42 AM, Loïc Antoine-Gombeaud wrote:

Hi chefs,

can somebody explain the rationale behind deployment callbacks, also
called deployment hooks [1]? More precisely, I understand their purpose
quite well (and use them myself), however I don’t understand why they
should be stored in the application code base instead of inside the
cookbooks.
According to Scalarium documentation [2], it is an inherited Capistrano
behaviour, but that doesn’t answer the question of location AFAICT.

The reasons I’m asking are the following:

  • it’s a pain to maintain deployment code in two distinct repositories, and
  • I’m just curious :slight_smile:

The deploy resource is a port of an earlier project that provided
Capistrano-style deployment for Chef, developed and used at Engine Yard,
and the intention was to provide compatibility with that implementation.
You can imagine that in an Engine Yard type scenario, you may be able to
fill in all the parameters to the deploy resource from information you have
in a database or with sane defaults for your environment, while allowing
some custom functionality via hooks that live in the code repo.

If you don’t want to keep the callback code separate, you can just give
blocks of Chef code to the callbacks instead of looking up the files.

Any pointers?

Cheers,
Loïc

[1]
http://wiki.opscode.com/display/chef/Deploy+Resource#DeployResource-InteractingwithYourInfrastructureDuringDeployment
[2]
http://support.scalarium.com/kb/deployment/how-can-i-use-deployment-callbacks


Daniel DeLeo


Loic ANTOINE-GOMBEAUD
IT contact & DevOps Engineer

Plinga GmbH | Saarbrücker Straße 20/21 | 10405 Berlin | Germany
E-Mail: loic.gombeaud@plinga.com | skype: loic.plinga
Cell: +49 (0) 160 922 86573

Geschäftsführer: Johannes Kreibohm, Florian Schmidt-Amelung
Eingetragen beim Amtsgericht Charlottenburg, HRB 119994


#4

On Friday, January 25, 2013 at 10:05, Loïc Antoine-Gombeaud wrote:

That’s really interesting, thank you for your answer. I’m going to digress here, but you’ve made me even more curious: is it common for open-source projects to implement features that benefit one user / group of users’ requirements, but not necessarily all of them? How is that decision made: is it a conscious, group-approved decision, or does it just “happen”?

That’s a very general question. Open Source software can be anything whose source anyone has opened to the world.

Sometimes it’s Wordpress, sometimes it’s a bash script to bootstrap my Unix user. The former is built thinking about all the users, the latter is built for myself. The reason why I might open my own scripts is that other people might benefit from what I did in some way – learning, applying similar design decisions, etc. Many people think of FOSS (Free and Open Source Software) as something that someone created to “scratch their own itch”, and many projects do start like that.

You have all sorts of shades in between those two extremes. :slight_smile:

I’m at the very beginning of my career and have never dabbled in open-source before, I must say I’m quite impressed by what a community of people scattered around the world can achieve, even knowing that there is often a core of developers based in the same physical place.

It is certainly incredible, specially when those projects are not directly (or even indirectly) backed by a company. I’d suggest you read more about the history and current state of the Linux kernel and the Debian project. While reading about Debian, do search for their Social Contract and other guiding documentation.

What would be a good reference for getting to know those work mechanisms better?
Mailing lists, blogs, IRC, user groups, github, DuckDuckGo :slight_smile:

Look for local user groups on topics of interest and make contributions to the communities. Github is your friend. That’ll send you a long way.

And, of course, pub talks with fellow geeks!

On Thu, Jan 24, 2013 at 5:09 PM, Daniel DeLeo <dan@kallistec.com (mailto:dan@kallistec.com)> wrote:

On Thursday, January 24, 2013 at 6:42 AM, Loïc Antoine-Gombeaud wrote:

Hi chefs,

can somebody explain the rationale behind deployment callbacks, also called deployment hooks [1]? More precisely, I understand their purpose quite well (and use them myself), however I don’t understand why they should be stored in the application code base instead of inside the cookbooks.
According to Scalarium documentation [2], it is an inherited Capistrano behaviour, but that doesn’t answer the question of location AFAICT.

The reasons I’m asking are the following:

  • it’s a pain to maintain deployment code in two distinct repositories, and
  • I’m just curious :slight_smile:

The deploy resource is a port of an earlier project that provided Capistrano-style deployment for Chef, developed and used at Engine Yard, and the intention was to provide compatibility with that implementation. You can imagine that in an Engine Yard type scenario, you may be able to fill in all the parameters to the deploy resource from information you have in a database or with sane defaults for your environment, while allowing some custom functionality via hooks that live in the code repo.

If you don’t want to keep the callback code separate, you can just give blocks of Chef code to the callbacks instead of looking up the files.

Any pointers?

Cheers,
Loïc

[1] http://wiki.opscode.com/display/chef/Deploy+Resource#DeployResource-InteractingwithYourInfrastructureDuringDeployment
[2] http://support.scalarium.com/kb/deployment/how-can-i-use-deployment-callbacks


Daniel DeLeo


Loic ANTOINE-GOMBEAUD
IT contact & DevOps Engineer

Plinga GmbH | Saarbrücker Straße 20/21 | 10405 Berlin | Germany
E-Mail: loic.gombeaud@plinga.com (mailto:loic.gombeaud@plinga.com) | skype: loic.plinga
Cell: +49 (0) 160 922 86573 (tel:%2B49%20%280%29%20160%20922%2086573)

www.plinga.com (http://www.plinga.com/)

Geschäftsführer: Johannes Kreibohm, Florian Schmidt-Amelung
Eingetragen beim Amtsgericht Charlottenburg, HRB 119994


#5

Thanks a lot Cassiano, looks like I have a busy week-end coming up :slight_smile:

On Fri, Jan 25, 2013 at 1:47 PM, Cassiano Leal cassianoleal@gmail.comwrote:

On Friday, January 25, 2013 at 10:05, Loïc Antoine-Gombeaud wrote:

That’s really interesting, thank you for your answer. I’m going to digress
here, but you’ve made me even more curious: is it common for open-source
projects to implement features that benefit one user / group of users’
requirements, but not necessarily all of them? How is that decision made:
is it a conscious, group-approved decision, or does it just “happen”?

That’s a very general question. Open Source software can be anything whose
source anyone has opened to the world.

Sometimes it’s Wordpress, sometimes it’s a bash script to bootstrap my
Unix user. The former is built thinking about all the users, the latter is
built for myself. The reason why I might open my own scripts is that other
people might benefit from what I did in some way – learning, applying
similar design decisions, etc. Many people think of FOSS (Free and Open
Source Software) as something that someone created to “scratch their own
itch”, and many projects do start like that.

You have all sorts of shades in between those two extremes. :slight_smile:

I’m at the very beginning of my career and have never dabbled in
open-source before, I must say I’m quite impressed by what a community of
people scattered around the world can achieve, even knowing that there is
often a core of developers based in the same physical place.

It is certainly incredible, specially when those projects are not directly
(or even indirectly) backed by a company. I’d suggest you read more about
the history and current state of the Linux kernel and the Debian project.
While reading about Debian, do search for their Social Contract and other
guiding documentation.

What would be a good reference for getting to know those work mechanisms
better?

Mailing lists, blogs, IRC, user groups, github, DuckDuckGo :slight_smile:

Look for local user groups on topics of interest and make contributions to
the communities. Github is your friend. That’ll send you a long way.

And, of course, pub talks with fellow geeks!

On Thu, Jan 24, 2013 at 5:09 PM, Daniel DeLeo dan@kallistec.com wrote:

On Thursday, January 24, 2013 at 6:42 AM, Loïc Antoine-Gombeaud wrote:

Hi chefs,

can somebody explain the rationale behind deployment callbacks, also
called deployment hooks [1]? More precisely, I understand their purpose
quite well (and use them myself), however I don’t understand why they
should be stored in the application code base instead of inside the
cookbooks.
According to Scalarium documentation [2], it is an inherited Capistrano
behaviour, but that doesn’t answer the question of location AFAICT.

The reasons I’m asking are the following:

  • it’s a pain to maintain deployment code in two distinct repositories, and
  • I’m just curious :slight_smile:

The deploy resource is a port of an earlier project that provided
Capistrano-style deployment for Chef, developed and used at Engine Yard,
and the intention was to provide compatibility with that implementation.
You can imagine that in an Engine Yard type scenario, you may be able to
fill in all the parameters to the deploy resource from information you have
in a database or with sane defaults for your environment, while allowing
some custom functionality via hooks that live in the code repo.

If you don’t want to keep the callback code separate, you can just give
blocks of Chef code to the callbacks instead of looking up the files.

Any pointers?

Cheers,
Loïc

[1]
http://wiki.opscode.com/display/chef/Deploy+Resource#DeployResource-InteractingwithYourInfrastructureDuringDeployment
[2]
http://support.scalarium.com/kb/deployment/how-can-i-use-deployment-callbacks


Daniel DeLeo


Loic ANTOINE-GOMBEAUD
IT contact & DevOps Engineer

Plinga GmbH | Saarbrücker Straße 20/21 | 10405 Berlin | Germany
E-Mail: loic.gombeaud@plinga.com | skype: loic.plinga
Cell: +49 (0) 160 922 86573

www.plinga.com

Geschäftsführer: Johannes Kreibohm, Florian Schmidt-Amelung
Eingetragen beim Amtsgericht Charlottenburg, HRB 119994


Loic ANTOINE-GOMBEAUD
IT contact & DevOps Engineer

Plinga GmbH | Saarbrücker Straße 20/21 | 10405 Berlin | Germany
E-Mail: loic.gombeaud@plinga.com | skype: loic.plinga
Cell: +49 (0) 160 922 86573

Geschäftsführer: Johannes Kreibohm, Florian Schmidt-Amelung
Eingetragen beim Amtsgericht Charlottenburg, HRB 119994