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" <jorginato...@gmail.com> 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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. 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.
