*More than just Jenkins, I love automation, but Jenkins is my favorite toy so far. I have also played with Supervisord for automations, but Jenkins seems to have won over my heart.
- Declarative Pipeline comes with Github Integration
I used to think of Jenkins as just a long running process manager. Then, I discovered that it integrates with Github, and that is a nice feature. Why do I like it so much? Well because I can run a script now whenever ANYONE pushes to a Github branch, and then report the result back to Github.
I can add this to any declarative pipeline:
pollSCM('') // build on Push to branchy
And now any time anyone pushes to their branch I can run whatever script or code I want, and then report back on Github the results.
It looks like this now when you do a Pull Request on your commit stack:
-A green check means your Job completed successfully.
-A red X means your Job failed or was aborted by user.
-A yellow circle means a build is in progress for that commit.
- Commits with no marking are inherited commits you pulled into your branch, not indicative of a push, so there is no need to do a build for those.
You can click on the checkmark or red x to be taken to exactly where in the console code the success or failure happened in Jenkins.
It’s so subtle I didn’t even notice the checkmarks at first.
2. I love Jenkins SO MUCH because testing is SO BORING
Testing is is like saving money.
Benjamin Franklin said a penny saved is a penny earned. Each penny saved increases your net worth by the same amount as if you had earned that same cent.
Testing is boring in the same way that saving money is, except you are saving your product, your code, your IP basically.
Not to mention, when I am testing, I often have to wait for something to finish processing, and a few user facing options can turn into a bunch of user action permutations really quick. Testing by hand is so boring, I could chew my own hand off. It’s extremely repetitive, we know all this.
If you start off by doing things on the command line, that you normally do via the mouse, you can start building little snippets of automation.
Once you become a command line native, automation becomes like second nature.
And once automation is somewhat second nature to you, then doing test driven development won’t be so intimidating, and seem to take so long.
3. Slick GUI
This sounds contradictory to what I just said before, which is that you should do as much as you can on the command line, so that automation becomes second nature to you. That is correct.
But, not everybody wants or needs to do this. eg. PMs, tech support, marketing etc. Perhaps some devs are pretty specialized, let them keep their interests narrow and specialized.
When your pipeline is sleek and bubbly people will be drawn to it. The GUI guy can send an installer to marketing so they can take screencaps, and the engine guy can spin off his own custom build for the BETA tester who has a uncommon computer config, and so on ad infinitum, ideally with about 1 to a few clicks, with a nice GUI explaining their options to them clearly.
Look at how pretty and bubbly that is, you know you want to use that.
I guess this is important to me because for a long time I felt like automation was how we were going to make release day not suck so much. But for a long time I could hardly get anyone to use my automation tools, even if I walked them all through it and everything. But, Jenkins stuck. I can get other people to use my Jenkins tools, and THEY WANT TO USE IT.