Need a Better Tool than Just a Terminal or Command Prompt?
Creating tools to help automate things for others on your team is a great way to increase productivity on the team. For very simple scripts, sometimes you don’t want to take the time to create a nice GUI interface for your scripts. The script might take an hour or two to write, but creating a front-end for it can eat up more time than you might want to spend on it. In addition, if you have several scripts, you would like the same front-end for all of those scripts.
Now, perhaps you have the time, knowledge, and desire to create a nice front-end for several of these scripts. If you are like me, however, you are not trained in creating nice-looking websites. That’s not to say that you couldn’t learn it, but it just isn’t your focus or priority. If this describes you, I’ve got a clever solution I have used in the past to get around this.
Generally, being able to click buttons is easier than knowing how to run something in the command line. That’s not to say others couldn’t learn how to do that, but allowing others to have a button to click makes your tools much easier to share and use, even for people who have very little experience with the command line. My solution uses a web interface – Jenkins. This assumes you have already set up a build server at your company. Preferably, most people know how to use that web interface. If not, some minimal training will be needed. At the conclusion of this post, you will know how to provide that web interface using Jenkins for your simple scripts.
If you need help installing or setting up Jenkins, you can refer to one of my previous blog posts: setting up Jenkins with Docker. Alternatively, you can visit their website to learn how to install it outside of Docker on Windows or Linux. It’s pretty straight-forward.
Jenkins provides a web interface, and each “job” (a task that runs something) has its own link from the main page. Once you go to the main page, you can create a new job and then navigate to it. You can see more about navigating the web interface and creating a job from one of my previous blog posts.
Once you create a job, you will have that front-end that you need. You can make a job accept “build parameters”. If your tool accepts arguments, this is the place to put them. For example, the below shows my jobs accepting an “SVN_USER” string parameter. My tool (which tags SVN code – you can read more about it here) takes an SVN username as part of its arguments. If your tool does nothing except a few Windows batch or Linux bash commands, you may be able to write your entire tool within Jenkins.
Now that you have the front-end that accepts arguments, you can simply call your tool within a bash or batch build step. Pass in the build parameters as arguments to your tool. You then have a front-end that calls into your script! An added benefit is you don’t have to worry about build environments. As long as the build server has the proper environment, everyone that uses your tool does not have to replicate that environment. (But if you want to do that, consider using Docker!)
Hopefully this helps you. I have created several simple scripts with a nice front-end by hooking up my scripts with Jenkins. This eliminates a good bit of development effort on my end by reusing the decent front-end already provided by this build server. In addition, hopefully people on your team know how to use it already; if not, perhaps now is a good time to learn (and teach them about continuous integration!).
Either way, let me know if you have troubles trying this. I hope you get as much use out of it as I have.