On Fri, Oct 2, 2015 at 11:01 AM, Thorsten Schöning
<tschoening_at_am-soft.de> wrote:
> Hi all,
>
> I'm doing a bit research for our somewhat small company how to best
> update home grown services, web applications and configurations on
> production and testing servers. We have only few of them, but many
> more working copies all over the place with various layouts, some
> applications even consist of independent wcs in different folders for
> historical reasons and such.
>
> There's a lot of tools available around the subject "continuous
> delivery", things like Puppet, Chef etc. are mentioned very often, but
Note that chef can be much, much ligherweight if you use "chef-solo".
I'm fairly active on the chef-devel list, and have actually irritated
a few developers by pointing out the advantages of using the "chefdk"
toolkit to with a source controlled local setup to allow localized,
single host deployment.
Mind you, that's a case where the local repository and the ability to
use a local branch without ever committing back to a central
repository can provide some advantages to git over the centralized
Subversion style deployment, and where development can be done on a
private branch without ever committing problematic or possibly broken
code to the central repository, and a private fork can be merged or
pulled form several distinct upstream repositories. I use it that way
myself, and would find it quite difficult to do remote development
with Subversion rather than local git repositorites. But tastes very.
Subversion has real advantages for some things. Continuious
integtration in Jenkins, with ocassional debugging and patching done
live in the Jenkins build environment? Not so much.
Received on 2015-10-03 02:36:48 CEST