Jenkins is showing its age

Jenkins has been a stalwart aid in all of the CI/CD projects I have worked on. Jenkins’ ease of use and plethora of plugins make it useful for almost any project and situation. From a build tool to a job scheduler Jenkins can solve your problem. But as with any good tool Jenkins has its drawbacks. For Jenkins the issue that gets me is that configuration is not stored in a git compatible format.  If I change a job configuration there is no way to rollback the change or even determine what the previous state was. If multiple teams have access to Jenkins your build server could go down with no means of rolling back a change on the whim of another team’s wannabe system administrator. 

Jenkins Pipelines are the Jenkins solution to storing job configuration in source control, but that is only for job configuration. Plugin configuration is still updated manually and easy to lose. It does make me wonder if we could make the /var/jenkins folder a git repository and just ignore the job history directories. 

While Jenkins pipelines are nice, I don’t want to code my entire build. I just want my changes stored in a git compatible format so I can easily roll them back. 

I also want to be able to mix and match pipeline stages with a standard stage interface for artifacts. Jenkins Pipelines allow me to mix and match ‘functions’ from a shared library, but not stages. Spinnaker purports to handle pipelines well, but it require me to run 10 different micro-services just to get started. That is not a replacement for Jenkins, maybe if Spinnaker was hosted by a 3rd party, it would be convenient enough, but Jenkins is free to setup. 

I will be using Jenkins today, but tomorrow I will have to start looking at alternatives.