Thursday, 15 December 2016
Re-visiting http://tim-pizey.blogspot.co.uk/2011/10/cvs-to-github.html (why did I not complete this at the time?)
On hanuman I created an id file git_authors mapping cvs ids to github name, email format for all contributors:
then create a repository on github (melati in this example, I already have uploaded my ssh public key for this machine)
git cvsimport -d /usr/cvsroot -C MelatiSite -r cvs -k -A git_authors MelatiSite
echo A jdbc to java object relational mapping system. 1999-2011 > README.txt
git add README.txt
git commit -m "Initial" README.txt
git remote add origin email@example.com:timp21337/melati.git
git push -u origin master
Saturday, 14 May 2016
The number of ways in which Maven, Surefire, Failsafe, Jacoco, Selenium and Jetty can be mis-configured is enormous.
I have explored this space and honestly this is the only one which worked!
JaCoCo UnitTest and IntegrationTest Configuration Example on github with results on a Maven generated github.io site.
Wednesday, 16 March 2016
Once you have Networking working there is still a long way to go.
yum groupinstall "Development Tools" yum install kernel-devel yum install kde-workspace yum group install "X Window System" yum groupinstall "Fonts" yum install gdm
Now we can login without a GUI but startx when one is needed.
Installing Guest Additions
The guest Centos is a stock distribution, you have to tell it that it is inside VirtualBox.
Make the additions visible to the guest:
In the "Devices" menu in the virtual machine's menu bar, VirtualBox has a handy menu item named "Insert Guest Additions CD image", which mounts the Guest Additions ISO file inside your virtual machine.
yum install dkms mkdir -p /media/cdrom # Note change from /dev/scd0 in CentOS6 mount /dev/sr0 /media/cdrom sh /media/cdrom/VBoxLinuxAdditions.run
We are now able to move the mouse seamlessly between our guest and host and window systems understand each other.
Sharing files between the host and guest
In the host (Windows) create C:\vbshared and using the VirtualBox interface share this with the guest. In the guest:
mkdir /vbshared mount -t vboxsf vbshared /vbshared
it will be visible as /vbshared/ from inside the guest.
The CentOS 7 iso does not enable networking during the installation, unlike Ubuntu. So your shiny new CentOS cannot get to the outside world.
Add the following to /etc/sysconfig/network-scripts/ifcfg-enp0s3
DNS1=18.104.22.168 DNS2=22.214.171.124 # Note this was set to no ONBOOT=yes
Friday, 4 March 2016
When starting a new project or joining an existing one there are a number of tools and features which should be in place. I have ordered them in order both of importance and the order in which the global community learnt the painful lessons that none of these are optional.
This is based upon Project initiation - a recipe.
Google it, ensure it is available as a url, check twitter.
If there is no README create it now!
The only decision is public or private. It will be a git repo.
If any other SCM system is in place convert to git before doing anything else.
Decide on git usage strategy: git flow, release branches, developer forks with feature branches and merge to master.
Do we really want to develop in Fortran under VMS? oh, OK.
Develop on the operating system you are deploying to. If you develop on OSX and deploy to debian it will bite you. Developing for Redhat using Windows should be made illegal.
Jenkins of course.
Track the code coverage, anything less than 100&percent; is not acceptable.
For legacy projects Sonar establishes a baseline, for new projects it holds the line throughout the projects life.
The closer to Continuous Deployment the fewer platform types are needed.
Metrics enable blue green deployment and A/B testing.
Issue tracking and work planning
Just you: gitthub, team: Jira
When your CI server is becoming too big to fail
This post was written when I was responsible for a heavily used CI server, for a company which is no longer trading, so the tenses may be a mixed
Once an organisation starts to use Jenkins, and starts to buy into the Continuous Integration methodology, very quickly the Continuous Integration server becomes indispensable.
The success of Jenkins is based upon its plugin based architecture. This has enabled Kohsuke Kawaguchi to keep tight control over the core whilst allowing others to contribute plugins. This has led to rapid growth of the community and a very low bar to contributing (there are currently over 1000 plugins).
Each plugin has the ability to bring your CI server to a halt. Whilst there is a Long Term Support version of Jenkins the plugins, which supply almost all of the functionality, do not have any enforced gate keeping.
A completely resilient CI service is an expensive thing to achieve. The following elements must be applied baring in mind the proportion of the risk of failure they mitigate.
Split its jobs onto multiple CI servers
This should be a last resort, splitting tasks out across slaves achieves many of the benefits without losing a single reporting point.
Split jobs out to SSH slaves
One disadvantage of using ssh slaves is that it requires copies of the ssh keys to be manually copied from the master server to the slaves.
Because jobs are initiated from master to the slave the master cannot be restarted during a job's execution (this is currently also true for JNLP slaves, but is not necessarily so).
The main disadvantage of ssh slaves is that by referencing real slaves they make the task of creating a staging server more complex, as a simple copy of the master would initiate jobs on the real slaves.
Split jobs out to JNLP slaves
This is the recommended setup, which we used eventually for most jobs.
Minimise Shared Resources
In addition to sharing plugins, and hence sharing faulty plugins, another way in which jobs can adversely interact is by their use of shared resources (disk space, memory, cpus) and shared services (databases, message queues, mail servers, web application servers, caches and indexes).
Run the LTS version on production CI servers
There are two plugin feeds, one for bleeding edge, the other for LTS.
Strategies for Plugin upgrade
Hope and trust
Up until our recent problem I would have said that the Jenkins community is pretty high quality, most plugins do not break your server, your ability to predict which ones will break your installation is small so brace yourself and be ready to fix and report any problems that there are. I have run three servers for five years and not previously had a problem.
Upgrade plugins one at a time, restart server between each one.
This seems reasonable, but at a release rate of 4.3 per day, seven days a week since 2011-02-21 even your subset of plugins are going to get updated quite frequently.
Use a staging CI server, if you can
If your CI server and its slaves are all setup using puppet, then you can clone it all, including repositories and services, so that any publishing acts do not have any impact on the real world, otherwise you will send emails and publish artefacts which interfere with your live system. Whilst we are using ssh slaves the staging server would either initiate jobs on real slaves or they too would need to be staged.
Use a partial staging CI server
You can prune your jobs down to those which are idempotent, ie those which do not publish and do not use ssh slaves, but the non-idempotent jobs cannot be re-run.
Control and monitor the addition of plugins
From the above it is clear that for a production CI server the addition of plugins is not risk or cost free.
Remove unused plugins, after consulting original installer
Plugins build up over time.
Monitor the logs
A log monitor which detects java exceptions might be used.
Backup the whole machine
Once a month restore from backup to a clean machine.
Store the configuration in Git
This process is only one element of recreating a server. Once a month restore from git to a clean machine.