Hacker News Reader

Comment by guruant | Hacker News Reader

We encourage our teams to set their utility scripts as Jenkins jobs (integrated with source control).

- The Jenkins job can have a friendly name, a description, a link to wiki article explaining how it works, and default inputs.

- Troubleshooting wiki articles also link back to the job (_"Getting this error? Try running this job"_)

- We don't need to worry about people having prerequisites on their machines (assuming they are installed on the Jenkins runner). They shouldn't even need to understand the language the script is written in, or how it works.

- You've got the opportunity to integrate and chain jobs together, or trigger them based on events.

- Pretty much everyone knows how to create and run Jenkins jobs

Of course having solved one problem (discoverability and organisation of scripts) you now have another one: Jenkins.

View on HN

We do this as well. Some additional benefits:

- Jenkins can manage credentials and inject them into your script, so you don't have to expose them to the user or put them in source control.

- You can easily add lots of helpful things like email and chat integration (e.g. have a job yell in Slack if the script fails).

- You can integrate Jenkins with Active Directory and require a user to be in a particular group to trigger a job.

- Jenkins gives you a centralized place to record audit logs of who invoked what.

Jenkins can be a pain to learn and manage, but its super powerful and worth while.

> Of course having solved one problem (discoverability and organisation of scripts) you now have another one: Jenkins.

I called this phase 2. Discovery, documentation and ongoing maintenance going to be the problem. We need to another jenkins to CI/CD the main tooling Jenkins.

My other though is that there is significant market for this kind of back office tooling clean up and ongoing maintenance. If we could come with a process to clean up and package it. we could sell it. I would definitely buy it cause it gives lot of time saving for day to day toils especially in operational space.

There are hosted CI solutions that can orchestrate locally installed agents. The two that come to mind are Microsoft’s Visusl Studio Team Services and AWS Code Deploy.

For both, you install a local agent that polls the website for commands. You can manually kick off a “deployment” that just downloads and run scripts. Both have agents for Windows and Linux.

VSTS is free for private environments for five users and like $5 a month for additional users for one simultaneously running agent - you can have as many agents as you want installed but only one will deploy at a time. Additional simultaneously running agents are cheap or free for each registered MSDN subscriber who is a user.

AWS Code Deploy is similar. It’s free for AWS hosted EC2 instances and a 1 cent for each on prem deployment.

They both support the concept of deployment groups where you can run the same deployments on a group of machines.

Code Deploy uses a simple YML file that tells Code Deploy which scripts/batch files to run.

They both support integration with GitHub via webhooks.

I'm intrigued by this. Maybe jenkins does more than I previously thought.

Jenkins is essentially a managed remote code execution engine. It can pretty much do anything you want it to

Reply on news.ycombinator.com