Hi On Wed, Oct 22, 2014 at 11:02:33PM +0100, Kulwinder Singh wrote: > Hey Karl > > Absolutely: we are moving towards a single code base, but there will always be > differences between our CI build and customer implementation ( we don't want > to > blow away all the dbdbables at the customer but we will do before every CI > build).
That sounds like a good candidate for an option in the installer - where the default is suitable for a customer. It also implies that your CI builds actually do not test upgrades - just clean installs. Testing of upgrades has to be done separately then. > So the question is, can I use ansible locally at a customer to deploy > artefacts > in the package (apologies, I am quite new to all of this right now)? Well - with different installation methods you will inevitably end up with *some* amount of duplication of functionality. The trick is to get it down to an acceptable level. Perhaps you can embed ansible into the actual installation? Ansible doesn't *have to* use SSH - it can run locally too - e.g. in "pull mode". This should allow you to re-use a lot of the code... Beware: I believe you can only redistribute ansible if the ansible license is compatible with the licence for your application. Since most of ansible is under GPL3+, this means you cannot embed it in your proprietary app without requiring the composite result to be GPL3+ compatible... According to the Debian packaging for Ansible 1.7, most bits of Ansible seem to be under GPL 3+, some bits are GPL2, OFL (new one on me), Apache-2.0 and even BSD-2. Alternatively, you can package your app as a "proper" *.deb or *.rpm package, and let the scripts inside do most of the grunt work. This should reduce the ansible playbook to basically "apt:" or "yum:" tasks... > > On 22 Oct 2014 22:57, "Karl E. Jorgensen" <[email protected]> wrote: > > Hi > > On Wed, Oct 22, 2014 at 02:38:01PM -0700, Kulwinder Singh wrote: > > Hi > > > > Our software is created using our CI processes: we build and deploy > artefacts > > of multiple technologies and test in the cloud. > > > > However, when we come to deliver the s/w to the customer, we end up > having zip > > files which are self contained: this contains scripts which can work > standalone > > to deploy the same artefacts to the customer in a similar (but not > exactly the > > same way) as our CI setup. This is of course because we can't ssh over > to our > > customers: they have separate networks and would not allow us to > continuously > > deliver to them! > > > > Can Ansible be used to create standalone packages to a customer > > site? > > Wouldn't it make more sense to use the same installation method > internally as externally? That should help flag up bugs in the > installation too... > > Obviously, you can still use ansible to drive the installation, but > the grunt work would then be done by the package itself... > > .. Just my 2p... > > -- Karl E. Jorgensen -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/20141022224932.GE32368%40hawking. For more options, visit https://groups.google.com/d/optout.
