Author: cb

by cb on Git, Stash, TFS

Removing TFS Source Control Bindings from Solution Files

Today, I started looking into removing the TFS source control bindings from all of our solution files. At the time, I didn’t know how many solution files we had, but I knew it was more than I wanted to go through manually. I did some research online and even found some tools, but they didn’t work correctly for me so I wrote a Python script that would do this for me.

Basically, you edit a single variable, providedPath and run the script. It goes through a directory (and all of it’s subdirectories) looking for solution files. It then goes through each file, finding where they start and end (if they are present), re-writes the file without that section, and replaces the original file. I’ve ran it today, build solutions to make sure I didn’t break anything, and checked that code into Stash. I’ve also build the whole app successfully.

The script is located on GitHub here.

One thing this script does not do that I might add is deleting .vccss files. I didn’t bother with it since I’ve added that file extension to the .gitignore files.

This might grow to do additional things as we test migrating from TFS to Git. My guess is that this will not be the last time I copy all of our source over. Oh, and we have nearly 200 solution files, half of which contain source control binding sections. I’m glad I scripted that.

 

EDIT: I’ve taken the script off of GitHub while I overhaul it and determine if I can actually share it.

 
by cb on Random

Database Backup Script

I just wrote a little script to backup the database of this blog. This script is absolutely not good for a production server and I do not warranty this to work correctly, but if you want something for backing up a DB this might not be a terrible way to start.

I have this script setup in /etc/cron.daily/ so it will run everyday at midnight. Keep in mind that the script must be executable for it to run.

Script

#!/bin/bash
# Backups WordPress database to the path defined below.
# Variables.
TIMESTAMP=$(date "+%Y-%m-%d-%H%M")
FILENAME=$TIMESTAMP.sql
FULLPATH=/path/to/db/exports/
DBUSER=username
DBPASS=password
DBSCHEMA=databasename
# Setting working directory to FULLPATH provided above.
cd $FULLPATH
# Execute DB backup command.
mysqldump -u $DBUSER -p$DBPASS $DBSCHEMA > $FILENAME

If the script is deployed like mine is, it’s executed by root, so you shouldn’t have to worry about permissions issues. Again, just remember the script is executable by doing this:

chmod +x /path/to/script.sh

Again, I don’t warranty this and it’s by no means a production quality script.

 
by cb on JIRA

The Importance Of Clear Error Logs

Once again, I’m reminded of just how crucial good error logs are. Last night our production MySQL instance went down, taking with it several missions-critical systems, namely JIRA. Of course, we didn’t know that at the time because JIRAs error logs never indicated a problem connecting to the DB, nor did at least one other affected application. Luckily, Stash had clearly put in the logs that the DB connection had timed out and we were able to use this information to go talk to DB guys to get this resolved.

I know that sometimes things fail in odd and unexpected ways and that this might not be a problem that could have been accounted for, but the takeaway is simply: make sure your logging is stout because it’s the difference between getting the system back up in a jiff or scratching your head.

This was the error that came up (in MySQL after we determined where the issue was).

141026 12:19:17 InnoDB: ERROR: the age of the last checkpoint is 9446264,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

It looks like we’ll need to some performance tuning to make sure we can handle large data blogs and large transactions.

 
by cb on Atlassian

Atlassian

Atlassian must be one of the most evil brilliant companies ever. They sell what, on the surface, appear to be amazing pieces of software, but underneath the surface there’s an ulterior motive. The reality is that you only get 75% of the functionality you need and are forced to buy add-ons offered by Atlassian or 3rd party software vendors to accomplish the remaining 25%. I buy the app, deploy it, realize I need it to do something else, and am forced to return to the market to purchase bolt ons. The vendors get paid, Atlassian gets their cut (and doesn’t have to develop anything if a 3rd party vendor has them covered), the admin is happy, and the users get some piece of functionality they really wanted. It’s only much later that I realize how light my coffers are and how slow my JIRA server has become.

They do platforms extremely well.

For the record, I like Atlassian. I’m mostly impressed with their software, what its capable of, and the community that’s popped up around it.

 
by cb on JIRA

JIRA REST APIs

JIRA has a collection of REST APIs that can be used for doing some tasks programmatically. I haven’t been using them for long but I’ve found three that are particularly useful.

I’m referencing to the 6.2.4 API doc which is found here. I used Python with Requests and the built-in JSON module to help parse through the responses.

reindex

If you want to re-index on a schedule, you can simply call this API and background indexing will start.

http://<jira_instance_url>/rest/api/2/reindex

If you get 200 or 202 back, then it means that indexing has been successfully started. If you 409 back, that means indexing has already started. The returned JSON will contain the % complete and the type of indexing.

project

If you want a list of all projects in your JIRA instance, you can call this API and you’ll get back a JSON list of them. You get several pieces of useful information back including the project URL, the key, and the friendly name.

http://<jira_instance_url>/rest/api/2/project

components

If you want to see a list of all the components for a particular project, you use the components API to fetch those.

http://<jira_instance_url>/rest/api/2/project/<project_key>/components

This may seem silly, but there doesn’t appear to be an easy way to produce a project chart from JIRA that would show this data. I recently used APIs to produce a Python script that dumps out each project and list of it’s components. For people who want to review this sort of thing, it makes their lives a lot easier. Below is an example of what it looks like, per project.

Project: My Cool Project
Key: MCP

UI/UX
Login
Core Functionality
Database
Security
APIs
======================================================

My only complaint with their APIs currently is that I cannot add versions via API and (as of 6.2.4) adding versions to multiple projects is tedious and error-prone because it’s so manual.

 
by cb on Random

Purpose and Intentions

I’m not entirely sure what my purpose of this blog is, but this seems like an interesting exercise. So, how about some background? I’m a release engineer at a software company in the Atlanta area. Currently, my duties include the following:

  • Managing our JIRA instance
  • Determining our migration path from TFS to GIT for source code management.
  • Determining our migration path from TFS to Bamboo for builds. In time, this will grow into full blown CI.

Looking at the list, it doesn’t seem like much, but I’m swamped a lot of the time and completely in over my head. I’ve never really dealt with SCM before outside of using git for personal projects. Also, JIRA is new to me too. With that being said, I love this. Previously I was a PM handling black sleep projects that no one else wanted to deal with. I didn’t enjoy that and requested a move. Luckily, I work for a great company and they were super accommodating and allowed me to jump into something completely new.

I guess the point of this is chronicling my experiences as a release engineer and any goodies/tidbits I come across along the way.