Split between CI on our servers, and releases to clients

[Kulwinder Singh]

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?

Kuli

[Karl E. Jorgensen]

Hi

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

[Kulwinder Singh]

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).

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)?

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/VpFaY_TRp30/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/20141022215717.GC32368%40hawking.
For more options, visit https://groups.google.com/d/optout.

[Karl E. Jorgensen]

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...

[Kulwinder Singh]

Thanks Karl, makes sense.