TeamCity - GitHub Commit Status Publisher

This morning one of the new guys in the team asked me if he could get notified when a pull request that has merged is built. Sometimes you just need someone to do the right question for you to notice that you could be doing things better.
After a few clicks in TeamCity I was able to configure a Build Feature to feed back the result of the build to GitHub. The only drawback is that there is no an easy way to configure it in the root of all the projects, so I'll have to add it one by one to the close to hundred build configurations we have.

Plug-in Configuration:

Refactoring Monolith Services and Git Contribution Stats

Today, a friend was having a look at my GitHub account and asked me about the large number of  private contributions I have. That made me look at the stats myself and then I noticed that I have been committing so much more than I expected to a single repository.

Of course, this is the repository of the "big monolith" my team and I have been refactoring and splitting in to multiple repositories for the last year, and the reason of that many commits to this "soon to be obsolete" repository is the approach we are taking.

Instead of rewriting the functionality in a new service straightaway, I have found that for very complex parts of the system, a good approach is to feature flag the functionality that is being rewritten and then rewrite it in the same solution along the old code using bridges and adapters to interface it. This way we can easily switch back an forth easily from old to new code and it also allows to write tests that can run on both implementations, but mainly it allows for a more progressive and less aggressive rewriting of the functionality.

A small trick is to create all the new projects in the same folder, that way when the code is stable enough, that folder can be split in to a new repository maintaining the history.