Why Use Jenkins to Tag in SVN?
I have used SVN in a couple of my jobs so far. In both locations I have used it, I created a job in Jenkins to help us do some relatively simple things in SVN (such as tagging).
While the process of tagging is not that difficult, there are still some good benefits to having an automated process for doing it.
- Anyone on the development team can do it, regardless of skill level.
- Most importantly, there is a standard process, location, and naming scheme for the tags.
I cannot stress that second point strongly enough. But before we dive into the details of those points, let’s look at why we need this process.
Our Deployment Process
I won’t go into all the details, but I will describe it from a high-level. We have two frameworks that go on two separate devices. In addition to those frameworks, we have project-specific code that works in those frameworks. So for any release, we have four different pieces of code to track:
- Framework #1
- Framework #1’s project-specific code
- Framework #2
- Framework #2’s project-specific code
That’s four different locations in SVN to tag. Unfortunately, we don’t deploy very often (every 3 months or so). Inevitably, every time we needed to deploy, it would be in a giant rush. We would forget the way we had done it before. This leads to inconsistent names and locations for our tags. Yuck!
I eventually got tired of this and automated it with a job in Jenkins.
Jenkins to the Rescue!
First, some vocabulary I use often:
firefighting (in the context of development): constantly debugging, never having enough time to ‘do things the right way’.
When the standard release cycle for your code is always in the midst of firefighting, the last thing you want to do is struggle with simple things. Your time is much better spent in developing infrastructure/fixing the actual issue/writing tests to help yourself in the future. The last thing you want to do is spend a non-trivial amount of time on something like creating SVN tags.
While documentation defining the process would be good, I feel that Jenkins is even better. Not only can you look at the job in Jenkins to see exactly what is happening, Jenkins can also do the whole thing for you. Simply click a button to build, input some arguments, then everything happens.
Here are the basic steps our tagging job in Jenkins does:
- As input arguments, input the…
- Framework/project versions
- Jenkins downloads the frameworks and projects from the appropriate location
- Jenkins then tags the code in the appropriate format using the project versions
The project versions are optional, so it can tag a subset of all four locations in SVN if needed.
Woohoo! We just automated away a tedious, error-prone part of our job! Now with just one button-click, stuff happens the right way, every time, on the first time.
Anyone on the Development Team Can Do It
Anyone with SVN credentials and the ability to determine what version number we are currently on can do this. They just go to the correct location in Jenkins, fill out that information, and build the job. The hardest part is finding the information to fill out those fields in the Jenkins parameterized job.
Standard Process, Location, and Naming Scheme
I’m not sure we ever had a problem with putting our SVN tags in the wrong location, but we did name those tags inconsistently. Whether it be a dash rather than an underscore, different capitalization cases, or something else, we didn’t do that part very well.
We could have documented it. However, it would not have been long before someone didn’t read the documentation or fat-fingered a name. Since we are always in a rush, we don’t take the time to fix it or have another person verify that name. In addition, who wants some diagram like the following…
when you could just have a button to press that takes care of it for you?
This goes back to my whole concept of ‘living documentation.’ If you want to see how the tagging process works, you can go view the actual commands in Jenkins. If it ever changes, it will be reflected in Jenkins… because that’s the actual process we use to tag our code.
One might say that’s too low level. You don’t want to see the actual commands, only the new SVN locations that were created.
If that’s the case, perhaps we could add a website that Jenkins automatically updates at the conclusion of that job. For example, we could publish the high-level information (perhaps only the locations in SVN that were created) to another website. That website gets updated every time the Jenkins job gets done. So the documentation still remains up-to-date every time we run that job. As of now, we haven’t needed something high-level yet. But if we do, that’s one way we might do it without worrying about stale information.
We definitely have a long ways to go with software automation/best practices at my company. That being said, it’s little things like this that, over time, go a long way to making us better. Consider how you might bite off small pieces of infrastructure to make your company better. Over time, you will be thanking yourself over and over. No need for the tedious parts of the job when a machine could do it for you.