Hack away at it until it works

I've always been sort of a read about something, hack away, fail, read some more, make some progress, read, fail, make some more progress and eventually get something working kind of person. I learn by doing and experimenting. This can be pretty embarrassing for me. Not because I'm embarrassed of just the action of doing this, but embarrassed about the trail it leaves behind.

I recently decided that I should look into doing some Continuous Deployment pipelines into some of my projects, specifically SSRSMigrate. Why? To learn some new things, and those shiny "Build Passing" badges on your GitHub README make your repository look a bit more legit.

See what I mean?

If you look at the commit history for my SSRSMigrate repository you'll see all of the mistakes I made along the way of getting the fancy little "build passing" badge from Appveyor working. Once I got that working, I had to get the "passing tests" badge, right? Of course! Yep, more embarrassing commits while trying to get the unit tests to display while building in Appveyor...

Then of course I had to look into a "code coverage" badge. Wow, 91% coverage? I still don't think that number is right. Resharper says it's about 79% for the SSRSMigrate project and 91% for the SSRSMigrate.Tests project... I'll have to read more about OpenCover but I'll probably just get rid of that badge eventually.

I saw a post about using GitVersion to do a bit better build versioning, so you'll see some more embarrassing commits related to that, then some removing those changes and then some commits trying to get GitHub release deployment working. Eventually I went with just triggering an Appveyor build whenever a commit is tagged in Git. I'm just using the tag's name as the version for the build and for the release that is deployment to GitHub releases. That seems to be working pretty good right now and I can definitely set the version myself instead of using an auto incremented build number from Appveyor.

I felt pretty accomplished after all this but have a pit in my stomach because of the embarrassing mess it left in the commit history in this repository.

Anyway, here is my CD setup for SSRSMigrate: https://ci.appveyor.com/project/jpann/ssrsmigrate

So, this is another personal goal for 2019. Don't be embarrassed about making mistakes while learning.

Edit: Well, I changed the build configuration to build on all commits to the master and develop branch and deploy only on master branch commits instead. Debating about whether or not whenever a commit is done to the develop branch if it will trigger the development build to get released to GitHub as a 'Pre-Release' or not. Mainly I'm considering this because of the way Appveyor versioning works, each time a build happens the build version increments, so right now every development build gets its version incremented (I'm using 'develop-N' as the development versions), so when you push to master, that build gets a continuing version number. For example, say you have a stable version 1.1.1, and development builds develop-2, develop-3, as soon as you merge the develoment branch into master, you will get a stable version of 1.1.4. Still trying to figure all of that out, but if I deploy each develop-N build to GitHub as a 'Pre-Release', it would make a bit more sense since you can see all the different pre-releases between each stable build.