Testing with Jenkins, Ansible and Docker • Hacker News Board

Re: Testing with Jenkins, Ansible and Docker

#21

Post by mateuszf » Sat, Apr 12, 2014, 8:08 AM UTC

Silhouette wrote: post #5

At the same time, we need to move fast with development and deliver updates as soon as possible. We want to be able to easily deploy several times per day. Genuine question, not intended as any sort of troll: what benefits would people with this philosophy say their organisation gains from routinely deploying multiple times per day? I have nothing against better testing tools or more efficient development processes,…

This book may be good read to you: http://www.thoughtworks.com/continuous-delivery

Re: Testing with Jenkins, Ansible and Docker

#22

Post by mpdehaan2 » Sun, Apr 13, 2014, 9:56 PM UTC

crdoconnor wrote: post #20

wiremine wrote: post #6

I've been using Ansible for a few production-related tasks lately, and think it's great. It provides the right level of abstraction, IMHO: you can crack open a playbook, read through it, and know exactly what it is doing. There's also a growing number of playbooks if you google around. That said, the biggest downside I've seen with Ansible is reusable components. They have something called Galaxy in beta [1], which s…

>That said, the biggest downside I've seen with Ansible is reusable components This was a major, major issue with puppet, too - although somewhat worse, in that the manifests were more unreadable. One issue that ansible still hasn't really solved is the horrible if/then/elses you have to put in to accommodate RHEL/ubuntu/centos/whatever else differences. I like that galaxy at least lets you specify which environment…

Check out the group_by module, as this can make those totally go away.

Re: Testing with Jenkins, Ansible and Docker

#23

Post by fit2rule » Tue, Apr 15, 2014, 11:50 AM UTC

wiremine wrote: post #6

I've been using Ansible for a few production-related tasks lately, and think it's great. It provides the right level of abstraction, IMHO: you can crack open a playbook, read through it, and know exactly what it is doing. There's also a growing number of playbooks if you google around. That said, the biggest downside I've seen with Ansible is reusable components. They have something called Galaxy in beta [1], which s…

Was quite surprised to see a lack of playbooks in Galaxy that have anything to do with installing/setting up the Java RE .. anyone know any reason why that may be the case?

Re: Testing with Jenkins, Ansible and Docker

#24

Post by gtaylor » Wed, Apr 16, 2014, 10:29 PM UTC

Silhouette wrote: post #19

gtaylor wrote: post #18

Earlier quoted context omitted.

> However, to me neither seems like a strong argument for routinely releasing multiple updates per day. I don't understand this line of thinking. If there's a bug that you can fix in short order, why not fix it and deploy said fix? If you've set your CI and infrastructure up correctly, update rollouts aren't something the user even notices. I've always been a big proponent of small, atomic commits. Being able to depl…

If there's a bug that you can fix in short order, why not fix it and deploy said fix? If you've got an important bug to fix, sure, of course you want it dealt with as quickly as possible. If you've set your CI and infrastructure up correctly, update rollouts aren't something the user even notices. Not if it's for a bug fix or security patch, but presumably most of your development work is adding new features? In that…

> So that brings me back to where I came in: do you experience any concrete, measurable benefits from the "excellent development velocity" you mentioned, or is it simply your team's preferred development style?

Yes, see the following:

> The customers love it, and we enjoy excellent stability and development velocity. These are the reasons we deploy many times a day. There's no reason for us not to deploy things once they are tested and ready.

We're not just deploying bug fixes quickly (which you seem to be fixating on a bit), we are constantly making small iterations. If we're handling support and see something that could be improved, we improve it and roll it out quickly. If we have a moderate sized feature branch, it is merged, tested, and rolled out immediately as soon as it passes QA. No need to set a rigid "We only deploy on Wednesdays" schedule. Pass QA, deploy immediately.

> Not if it's for a bug fix or security patch, but presumably most of your development work is adding new features? In that case, isn't the whole point that it's something the user will notice?

No, a huge chunk of dev time is spent iterating on and improving existing features. There gets to be a point in a product's life cycle where you are more or less feature complete, where the emphasis shifts to refining and improving what you already have. Sure, there are new features, but if you never iterate, you've got older stuff accumulating dust and ageing badly.