I recently got around to implementing some Jenkins promotion processes for one application. This is the first time I setup promotions for any of our builds. It has been on my to-investigate list for a long time though.
So far, it is working out nicely. We are on an older Jenkins version for now and I think the 2.x version has some significant workflow additions which I hope to try out sometime (sooner than later). Even with the older Jenkins/promotion setup, it is nice having some workflow in place and manageable from one place. For various reasons, most of the processes are manually initiated except the first one (which results in deployment to a dev server after a build which is initiated when SCM changes are found during polling).
One thing that might be nice is a way to schedule a promotion once criteria are met. With some effort, this is probably possible with some custom code and/or more jobs but having a more direct way would more convenient. My intent with this would be to use promotion to perform deployments, outside of normal use hours, to systems used for testing/training so as to not disrupt activities. I guess another option is to change the deployment processes so that promotion simply queues up the artifacts that a separate deployment process then handles. I'll have to think that one through further; for now the recent changes are at least a positive step forward.
Another item of research is whether the promotion process definitions can be simplified/shared somehow. I didn't put time into simplifying it upfront, instead I just wanted to make sure it was correct. As long as the maintenance cost is lower than the benefits I won't complain but reducing non-development time wasters is always a plus so I will hope for continued improvement.
No comments:
Post a Comment