Answers: <p>For a laptop, desktop or standalone server, consider trying out <a href="https://www.docker.com/" rel="nofollow noreferrer">Docker containers</a>. These containers are designed to allow you to provide differing libraries, packages and shared objects uniquely to each application.  You can have several different Docker containers running different and even conflicting libraries for the same application. You should be able to then use these to package and compile your RPMs.</p>
  
  <p>Because these containers run on a single kernel instead of having to power the overhead of multiple kernels, you will be able to run more simultaneously. Furthermore, because Docker uses the underlying file system and <a href="https://en.wikipedia.org/wiki/Docker_(software)" rel="nofollow noreferrer">creates unions</a> instead of keeping an entire second copy of a whole disk image, managing and cloning containers is faster, lighter weight, will require less storage and since there is no boot sequence to go through, they should start and stop faster.</p>
  
  <p>They are also compatible with Jenkins, TeamCity, Vagrant and several other build server software suites, AWS/EC2 and many configuration management systems.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-07-12T16:28:02.107Z
Answers: 2017-07-12T16:28:02.107Z
Answers: James Shewey
Answers: <p>Have you considered setting up a build server (i.e. Jenkins, TeamCity) with disposable build agents?</p>
  
  <p>If you do it in the cloud (i.e. via ec2 integration), you can literally set up an AMI with generic dependencies, then configure it to spin up a new VM for each build agent, which can be configured whichever way, and then delete the VM once you've done publishing your artifact (i.e. RPM).</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-07-11T22:21:24.003Z
Answers: It sounds like he is using VMWare based on his comment "just load the ova file"
Answers: James Shewey
Answers: CC BY-SA 3.0
Answers: 2017-07-12T03:49:56.420Z
Answers: It would work the same way, though.  VMware does have a decently powerful API, which you can also utilize through config management.  You could bake a VM with required dependencies (i.e. build agent, gcc, git, npm, etc), snapshot it, and then use this Ansible module to clone it as needed: http://docs.ansible.com/ansible/vsphere_guest_module.html.  
  
  OP's problem is time management and overhead, and proper automation is the solution to that.  Specific tooling is irrelevant.
Answers: maplebird
Answers: CC BY-SA 3.0
Answers: 2017-07-12T06:33:21.890Z
Answers: I'm using virtualbox, on some development machine, not a build server.
  Vshpere server can help in this case? and what would be better? VM or something like Jenkins?
Answers: Amit Arie
Answers: CC BY-SA 3.0
Answers: 2017-07-11T21:56:49.577Z
Answers: 2017-07-11T21:56:49.577Z
Answers: maplebird
Body: <p>I am constantly delivering RPM packages upon every new version of some project.</p>
  
  <p>Every version is dependent on some developing prerequisites</p>
  
  <ol>
  <li>CentOS 7</li>
  <li>git</li>
  <li>Some npm packages.</li>
  <li>Some Python PIP packages</li>
  <li>Some shared objects</li>
  </ol>
  
  <p>I'm dealing with this issue currently with having a virtual machine for every release, and that is very convenient to release every version - just load the ova file of the specific machine and you are ready to go.</p>
  
  <p>but the problem is, the overhead of dealing with virtual machines:  cloning and other operations - taking too much time.</p>
  
  <p>What do you recommend in order to do it much more easier? </p>
  
Comments: CC BY-SA 3.0
Comments: 2017-07-10T17:07:35.373Z
Comments: What infrastructure are you using for your VMs? Have you considered using Docker containers?
Comments: James Shewey
Comments: CC BY-SA 3.0
Comments: 2017-07-12T06:35:10.747Z
Comments: Would it be better? i'm using VirtualBox
Comments: Amit Arie
Comments: CC BY-SA 3.0
Comments: 2017-07-12T21:44:57.073Z
Comments: Please [edit] your question to add what you're using and context
Comments: Tensibai
Tags: <release><builds>
Title: RPM's, VM's : time consuming
UserDisplayName: Amit Arie
ThreadText: # RPM's, VM's : time consuming
  
  (Asked by: username_0 on 2017-07-10)
  
  I am constantly delivering RPM packages upon every new version of some project.
  
  Every version is dependent on some developing prerequisites
  
  1. CentOS 7
  2. git
  3. Some npm packages.
  4. Some Python PIP packages
  5. Some shared objects
  
  I'm dealing with this issue currently with having a virtual machine for every release, and that is very convenient to release every version - just load the ova file of the specific machine and you are ready to go.
  
  but the problem is, the overhead of dealing with virtual machines: cloning and other operations - taking too much time.
  
  What do you recommend in order to do it much more easier?
  
  **Tags:** release, builds
  
  > **Comments:**
  > **username_1**: What infrastructure are you using for your VMs? Have you considered using Docker containers?  
  > **username_0**: Would it be better? i'm using VirtualBox  
  > **username_2**: Please [edit] your question to add what you're using and context  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-07-12. Score: 2
  
  For a laptop, desktop or standalone server, consider trying out [Docker containers](https://www.docker.com/). These containers are designed to allow you to provide differing libraries, packages and shared objects uniquely to each application. You can have several different Docker containers running different and even conflicting libraries for the same application. You should be able to then use these to package and compile your RPMs.
  
  Because these containers run on a single kernel instead of having to power the overhead of multiple kernels, you will be able to run more simultaneously. Furthermore, because Docker uses the underlying file system and [creates unions](https://en.wikipedia.org/wiki/Docker_(software)) instead of keeping an entire second copy of a whole disk image, managing and cloning containers is faster, lighter weight, will require less storage and since there is no boot sequence to go through, they should start and stop faster.
  
  They are also compatible with Jenkins, TeamCity, Vagrant and several other build server software suites, AWS/EC2 and many configuration management systems.
  
  
  ---
  
  ### Answer by username_3 on 2017-07-11. Score: 2
  
  Have you considered setting up a build server (i.e. Jenkins, TeamCity) with disposable build agents?
  
  If you do it in the cloud (i.e. via ec2 integration), you can literally set up an AMI with generic dependencies, then configure it to spin up a new VM for each build agent, which can be configured whichever way, and then delete the VM once you've done publishing your artifact (i.e. RPM).
  
  > **Comments:**
  > **username_1**: It sounds like he is using VMWare based on his comment "just load the ova file"  
  > **username_3**: It would work the same way, though.  VMware does have a decently powerful API, which you can also utilize through config management.  You could bake a VM with required dependencies (i.e. build agent, gcc, git, npm, etc), snapshot it, and then use this Ansible module to clone it as needed: http://docs.ansible.com/ansible/vsphere_guest_module.html.    OP's problem is time management and overhead, and proper automation is the solution to that.  Specific tooling is irrelevant.  
  > **username_0**: I'm using virtualbox, on some development machine, not a build server. Vshpere server can help in this case? and what would be better? VM or something like Jenkins?  
  
  ---
  
  