Discussions

News: Automating a complex build process

  1. We have a relatively complex build process in place which has taken a roughly a manyear to reach to its current status. The post is about our experience on multi-platform java apps. We have built a javaagent supporting Linux, Windows, Mac and Solaris. On 32 and 64 bit JVM. And on Hotspot, jRockit and IBM JDKs. Running on most of the application servers out there. If you think it was a trivial problem - Java is supposed to be written once and to be ran anywhere - guess again. Our architecture contains elements making the case interesting - we have native code usage, embed a graphical UI, integrate with different application servers and verify the release on 50+ different configurations At first place, we have something quite peculiar in place with Jenkins is orchestrating the mess: Linux boxes in Amacon EC2 Mac Minis for the Mac support Windows instances in VirtualBoxes An ancient physical SPARC box. We are using a Bitbucket code repository for the source code repository, which we build using Gradle scripts and makefiles. The build on different platforms is governed by a Jenkins node which builds deliverables to the Artifactory repository. To see how we managed to achieve this - check out the blog post http://plumbr.eu/blog/automating-a-multi-platform-build
  2. You say: "If you think it was a trivial problem - Java is supposed to be written once and to be ran anywhere - guess again." Sure, you then clarify that you have native code and other issues. So then why compare yourself to a Java application in the first place? You don't have a "Java" application. You have a hodgepodge of stuff. Sorry if this sounds nitpicky. It just sounded very disingenuous to me. I've worked on MANY projects where Java was run on multiple operating systems, with no recompile, and no issues. Not saying it doesn't happen. Just saying that Java is pretty damn good at being cross-platform (from what I've personally experienced).
  3. This is actually what pretty much multi platform development teams face. This again would raise its ugly head when you have to support multiple customers with their individual intricacies. The pain we have experienced in just getting a development/build process and deployments into multiple environments  prompted us to create this product called cloudMunch. A dev-ops platform integrating build, test and deploy processes and integration with most of the cloud providers/ on prem VM and openstack and also with adapters to communitcate with a multitude of ALM tools from SCM to issue tracking. There are plugins for jenkins available and myriad of sciting tools but cloudMunch as a platform tries to simplify to the extent that you can reuse whatever you have bult/scripted and create orchestration steps/apps on the fly. Wondering if something like cloudMunch would have helped in a scenario like yours.