Versioning software is a large topic. When working in an Agile Software environment, where you’re releasing small, frequent releases it can be very difficult to know what goes in to each release. On a large enterprise project I work on, we maintain several APIs. Consumers interact with these APIs from a Thrift interface. They are primarily interested in knowing what version of the API has my request? On this project we push builds out to internal customers multiple times a day. Our build server can also create builds off feature branches so the builds are in various states of done. Keeping track of what changes are in what version is a full time job. It’s also a job that’s easily automated with. Enter…
The Release Manager!!!
Enter the Release Manager. The Release Manager monitors an artifacts folder and computes the differences between class files that it is tracking. For my application I’m interested in versioning thrift interfaces so it converts the C# changes to the relevant thrift IDL interface. Say what? Yup. It is a bit of a hack to go from C# to Thrift. The hack works surprisingly well. So well that I think this could be extended to make a very cool Code-First-Thrift-from-C#-tool.
The code is definitely a little rough and specific to my problem space. It is data-driven, but I would guess code changes are needed for most different applications. If I find time, I’ll look at extending and generalizing the solution.
There are two inputs to the release manager:
1. A folder with sub folders for each build. Each sub folder has .Net assemblies.
2. A git repository.
There is a hard requirement that the folder name includes the shortened GIT hash; Alternatively the shortened git hash can be stamped in one of the assemblies.
Atlassian JIRA integration is optional and requires Atlaassian Stash and a specific GIT workflow. The GIT workflow requires feature branches to be named the same as a JIRA ticket and feature branches are merged using pull requests. With this workflow, the Release Manager can associate specific JIRA tickets with each version of compiled software.
There are two additional dependencies:
1. A SQL database for storing differences
2. A IIS site for viewing differences
There are four stages to processing changes. Each of these stages have a unique command line parameter. Each of the stages can be run independently of the others.
* –artifacts | Scans through the artifacts folder and adds new artifacts to SQL database
* –setPreviousId | Scans the SQL database and figures out the order of the artifacts
* –processDiff | Process artifacts in SQL and computes the differences between versions
* –jiraFromGit | Scans through the JIRA ticket numbers and finds the associated GIT commits
Architecture – Component Diagram:
The components and their interactions can be seen here. A major driver of the tool was for this to be simple and loosely coupled, while providing definitive information that is integrated with our GIT source control, JIRA ticketing system and build server. whatsgoingon.exe is designed to be run as a windows scheduled task to provide near real time information about what changes are made to each and every build.
All source code can be found on Git Hub at: https://github.com/marksl/whatsgoingon
Below are pictures of a large enterprise project. On Git Hub there’s also a that can be generated by running create-db.sql, build.bat and whatsgoingon.exe –artifacts –setPreviousId –processDiff.