Can fly CLI tool be used for any Concourse machine? - continuous-integration

Im working with Concourse and using the fly cli tool. When I create any new VM or instance running Concourse it will immediately give me the option to download the fly cli tool.
Is this version of fly specific only to the machine I downloaded it from or will it work on any machine running Concourse?

fly will warn you its version is too different from the target, and prevent itself from running if the discrepancy is too large (a major or minor version difference), in which case you should run fly sync.
If it's not warning you, you should be fine.

Related

How to upgrade WebSphere Application Server from 8.5.5.0 to 9.0 using command line?

I have WebSphere Application Server v8.5.5.0 installed on my machine and want to upgrade WAS to v9.0 without uninstalling the current version. How can i do that using the command line as after we successfully upgrade on local machine we need to upgrade WAS on Production Linux server as well. Can anybody help on this with steps?
You can install two versions of WAS side by side, that'll work fine. From there, you can migrate your profiles over using WASPreUpgrade and WASPostUpgrade; I use the steps here: Migrating a cell using the command line tools. Make sure to take good backups of your environment, in case you want to roll back or re-do part of the process.
The command reference for WASPreUpgrade and WASPostUpgrade are useful as well.
Personally, I'd also make sure you install the latest fixpack for 9.0 that you possibly can--each one resolves a bunch of possible bugs and pitfalls.

Running Jenkins slave on different OS than master (and host)

I'm trying to introduce continuous integration in an old project, and we've got quite specific situation - it's possible to put the CI server only on our test server that runs on CentOS. The server has quite a lot of unused RAM and CPU capability.
However, we need to run Ant builds on Windows (this also used to be how the project did packaging before), however it turned out that not the same output (after binary compare) is produced by just using Unix versions of Java and Ant.
I drew up a diagram of how in my mind it could work, but I'm really wondering whether that is even possible (with already given tools).
The black part is implemented, I'm curious whether the red part could be possible. Could the Jenkins slave communicate with master on different OS?
It should be possible. I have a feeling you will need to play with your network settings. But if before you start changing anything see if you can start a headless slave by following these directions: https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machine
Using VirtualBox for CentOS, it will possible to run a Windows VM on your CentOS host.
I'm not sure you need Docker to launch your Jenkins slave.
It maybe better to use a standard JNLP Windows service to connect your Windows slave to Dockerised Jenkins master.
If the master is not able to view the Windows node using this method, you may have to tweak your network configuration on the Windows VM.
But I'm not sure it's necessary.

Whats the best fit for continious delivery, Vagrant or Puppet,

At present I have to deploy the latest version of my application to a QA environment which is a painful and completely manual task. Im looking at possibly using Puppet or Vagrant as a way to manage my infrastructure and spin up some virtual machines with all the components I need so I can run acceptance tests against the latest version of my software. Im looking for something that integrates with my Bamboo and will teardown these machines when im finished with them.
Theres alot of talk about Vagrant, but it seems to me that you need to first prepare a VM before using Vagrant. Is one better than the other or is anyone using both as part of there CI environment?.
Why or when you can use "and":
Puppet is a configuration management tool - forcing consistency and predictability across your cluster. Usually used in Staging/Production set ups where autoscaling of machines is used.
Vagrant is a simple framework for setting up virtual machines from a list of pre-configured "clean" installations. The first use case is a "playground" on your development machine.
Once Vagrant sets up the virtual machine it can provision it using Puppet to install all the prerequisites (e.g. your app) (just like it does in the production machines) and then you can test it.

VMware Workstation 8 automation with Ruby/Rake?

I'm looking into doing more automation in our build process; We use TeamCity and rake for our build tasks. We build our website into an MSI, and that's the extent of our CI system. I want to add deployment to the automation.
We use VMware Workstation so I want to add a build task to:
Revert a VM to a certain snapshot.
Install the MSI on the VM.
Run some acceptance tests on the live environment.
Does anyone have any advice on the best way to achieve this goal?
I've seen the following but not sure if they're suitable:
Vixr seems like it might be usable through my rake tasks, but I am not sure as it's quite old and I don't know the compatibility with Workstation 8.
RVC looks good but I don't think it's compatible with VM Workstation.
For simple tasks, you should consider using vmrun.exe exists in every workstation installation folder.
Manual is here: vmrun Documentation

Creating a virtual machine image as a continuous integration artifact?

I'm currently working on a server-side product which is a bit complex to deploy on a new server, which makes it an ideal candidate for testing out in a VM. We are already using Hudson as our CI system, and I would really like to be able to deploy a virtual machine image with the latest and greatest software as a build artifact.
So, how does one go about doing this exactly? What VM software is recommended for this purpose? How much scripting needs to be done to accomplish this? Are there any issues in particular when using Windows 2003 Server as the OS here?
Sorry to deny anyone an accepted answer here, but based on further research (thanks to your answers!), I've found a better solution and wanted to summarize what I've found.
First, both VirtualBox and VMWare Server are great products, and since both are free, each is worth evaluating. We've decided to go with VMWare Server, since it is a more established product and we can get support for it should we need. This is especially important since we are also considering distributing our software to clients as a VM instead of a special server installation, assuming that the overhead from the VMWare Player is not too high. Also, there is a VMWare scripting interface called VIX which one can use to directly install files to the VM without needing to install SSH or SFTP, which is a big advantage.
So our solution is basically as follows... first we create a "vanilla" VM image with OS, nothing else, and check it into the repository. Then, we write a script which acts as our installer, putting the artifacts created by Hudson on the VM. This script should have interfaces to copy files directly, over SFTP, and through VIX. This will allow us to continue distributing software directly on the target machine, or through a VM of our choice. This resulting image is then compressed and distributed as an artifact of the CI server.
Regardless of the VM software (I can recommend VirtualBox, too) I think you are looking at the following scenario:
Build is done
CI launches virtual machine (or it is always running)
CI uses scp/sftp to upload build into VM over the network
CI uses the ssh (if available on target OS running in VM) or other remote command execution facility to trigger installation in the VM environment
VMWare Server is free and a very stable product. It also gives you the ability to create snapshots of the VM slice and rollback to previous version of your virtual machine when needed. It will run fine on Win 2003.
In terms of provisioning new VM slices for your builds, you can simply copy and past the folder that contains the VMWare files, change the SID and IP of the new VM and you have a new machine. Takes 15 minutes depending on the size of your VM slice. No scripting required.
If you use VirtualBox, you'll want to look into running it headless, since it'll be on your server. Normally, VirtualBox runs as a desktop app, but it's possible to start VMs from the commandline and access the virtual machine over RDP.
VBoxManage startvm "Windows 2003 Server" -type vrdp
We are using Jenkins + Vagrant + Chef for this scenario.
So you can do the following process:
Version control your VM environment using vagrant provisioning scripts (Chef or Puppet)
Build your system using Jenkins/Hudson
Run your Vagrant script to fetch the last stable release from CI output
Save the VM state to reuse in future.
Reference:
vagrantup.com
I'd recommend VirtualBox. It is free and has a well-defined programming interface, although I haven't personally used it in automated build situations.
Choosing VMWare is currently NOT a bad choice.
However,
Just like VMWare gives support for VMWare server, SUN gives support for VirtualBOX.
You can also accomplish this task using VMWare Studio, which is also free.
The basic workflow is this:
1. Create an XML file that describes your virtual machine
2. Use studio to create the shell.
3. Use VMWare server to provision the virtual machine.

Resources