I have used automated build tools on all my projects since 2000. Back then it was CruiseControl in all its XML-configuration glory. Today it is usually Jenkins, or sometimes TeamCity, and I recently tried out ThoughtWorks Go. The user interfaces have generally improved over time, and now there is probably a “plugin for that” thing you used to script manually, but overall not much has changed in the last 15 years.
In fact, I feel that The Build is actually flakier now than it was then, mostly due to the increased complexity.
Take the typical Java stack for example. I have an AngularJS GUI, talking to a server via a REST API implemented in Java with Spring, which persists everything in a PostgreSQL database. There are 3 distinct languages involved (Java, JavaScript and SQL) which all require their own distinct cornucopia of tools. Each has their own testing framework, and the build box is Windows, but it is deployed to a Linux box.
Co-ordinating this build in Jenkins is a shit-show. I need npm, bower, and grunt plus protractor/selenium for the front-end. I need Java and Maven on the server-side, plus RAML for the REST docs, and then Apache2, Tomcat and PostgreSQL on the test server.
Now I have 5 Jenkins jobs (back-end build/test, front-end build/test, acceptance test, QA deploy, doc generation) all hobbled together and limping around the server like a zombie. Speaking of zombies - the Protractor tests rarely shutdown the Selenium server properly so those processes prevent the “npm install; bower install” dance from working, so now there is an extra grunt task that uses curl to shut down the Selenium server. There are SSH and SCP steps, Maven plugins doing remote deployments to Tomcat, remote PSQL scripts migrating the database with Flyway, and no meaningful way to do “one binary, all environments” in Maven.
ThoughtWorks Go addresses some of these issues by making Pipelines a first-class citizen. It shows promise, but the diagram on the front page of the website bears little resemblence to the UI itself. It has its own artifact repo to solve the “one binary, all environments” issue, but there is not an obvious way to get my Maven dependencies to use it. This is a problem with Maven itself, not Go, but it is a problem nonetheless Oh, and it is really just an elaborate CruiseControl under the hood. Everything old is new again if you put a snazzy UI on it.
Maybe it is time to accept that our Continuous Integration and/or Continuous Deployment process is in fact just a series of very complex batch jobs like we used to run back in the 90s. We already have tools for that and they are very mature. What do you think? Can you build a CI/CD flow in AutoSys or Tidal?