DevOps - Agile / Deployment Pipeline & Continuous Delivery - What creates the VM?

[worzelGummidge]

I am new to all of this Agile / Deployment Pipeline & Continuous Delivery stuff and have a question that I have not really been able to find out.


Working from the Ops side of the barrier (oops sorry no barrier, wiggly line then) in the deployment of code on VM's. I understand that there is a source control and release process with the VM's being build using say Ansible or Puppet but what actually creates the base VM with the basic OS?


Am I missing something?


I understand that the above can be Agile and continuous with lots of communication, or slow and painful with lots of bad feeling but how is the creation of VM's handled in VMWare or AWS or anywhere really.
Are we still using "Gold images", copy the image several times to the number of VM's required and then build from the base OS using the agile method?


How is the base VM building actually agile though? is that not slower then the rest?


I am confused.

[DimPrawn]

I've no idea, all the build/deployment/test/support and downstream stuff is handled by Bobs at the client.

[GlenW]

I've no idea, all the build/deployment/test/support and downstream stuff is handled by Bobs at the client.

Badly then?

[DimPrawn]

Badly then?

No.























Extremely badly.

[NickFitz]

I, and current ClientCorp, use Vagrant to bring up (and take down) VMs.

As a rule, a developer will re-provision a running VM most of the time, which is pretty fast, though some changes may require a new VM to be tested properly. A final full-blown deployment to a new VM is advisable before committing changes upstream, but that shouldn't be happening often enough for it to become a drag on development.

The CI framework can afford the luxury of provisioning new VMs from scratch, as nobody is sitting there drumming their fingers waiting for it - or at least, they shouldn't be.

[stek]

xCAT is your friend, it can deploy Linux via kickstart and AIX via NIM.

If your are a SPARC Solaris shop, AI is your friend as you can wan boot and not have to faff with DHCP.

[GlenW]

xCAT is your friend, it can deploy Linux via kickstart and AIX via NIM.

If your are a SPARC Solaris shop, AI is your friend as you can wan boot and not have to faff with DHCP.

That's magnifold in the wetty grippers.

[stek]

That's magnifold in the wetty grippers.

I actually creamed myself typing it.....

[worzelGummidge]

I, and current ClientCorp, use Vagrant to bring up (and take down) VMs.

As a rule, a developer will re-provision a running VM most of the time, which is pretty fast, though some changes may require a new VM to be tested properly. A final full-blown deployment to a new VM is advisable before committing changes upstream, but that shouldn't be happening often enough for it to become a drag on development.

The CI framework can afford the luxury of provisioning new VMs from scratch, as nobody is sitting there drumming their fingers waiting for it - or at least, they shouldn't be.

Your a star Nick. Thanks. I have been wondering about that.

My last two contracts (same place different clients) used Puppet and Ansible and I used to provision the systems the way that I was asked two, which was to a VM already setup.

If using Ansible then it would be initiated from the Ansible server host.
If using Puppet then it would be initiated from each client, which seemed a bit odd to me.

Hence... been wondering if it was time now me to do some proper Ansible or Puppet / Chef contracts but I did not really understand how the VM build bit worked in the "real world" without the manual stuff that the last contracts used.

Thanks.

I have actually already bought a Vagrant book but not read it.
Time for some reading then.

[SpontaneousOrder]

using the agile method?

say what?

How is the base VM building actually agile though?

I'm not sure the question even makes sense.


It sounds like you got the info you were looking for. Just think it might be a mistake to conflate what's going on with 'Agile'. Not saying the two aren't associated - just that your wording (i could be mistaken) makes me think that you'd be better learning a bit more about what agile development actually is before you assume that one necessitates the other.

Just mention it because I meet so many people with funny ideas about what agile actually is (i.e. 'do a, b and c and you are certified agile - whatever that means').

Apologies if I just misread your post.