Installing and configuring SonarQube with Azure DevOps/TFS

8 min read Our team follows a process adapted from Microsoft’s Release Flow [see: https://blogs.msdn.microsoft.com/devops/2018/04/19/release-flow-how-we-do-branching-on-the-vsts-team/], in which we create a branch off develop (our long-running mostly-stable product), do our work, commit it (with the PBI/Bug number in a comment), push the branch, then go into TFS and create a pull request. TFS will suggest a shortcut link to create a PR for the branch you just pushed to your default branch (in our case develop); or you can click the New pull request button and choose your source and target branches.


Application Lifecycle Management / World-Class DevOps

9 min read

Development process

Scrum team, planning work in 2 week increments, reacting fast to change, following best practices in research, planning, architecture and writing software. The team’s focus is on building great software, so we want them focused on what’s important.

  • As a developer, I take on a new feature or bug that’s in the sprint and ready for development, and marks it as development in progress.
  • Then I create a new branch off of develop, and do the work.
  • Then commit one or more times, and mention #[Work Item Number] in the commit message, along with a description of what changed
  • Once I consider the work complete and “tested” locally on my computer, I’ll push the branch, go into TFS and click the shortcut to create a PR

* develop is locked, so all changes have to enter via Pull Requests
  • On the next page I’ll make sure everything looks good, by doing one more check of the changes in the code, and click Create
  • Done and move on to greater things …

Publishing Swagger API Documentation to Confluence during Release

3 min read We use Confluence for our company’s documentation, and as such we need to keep samples and documentation up-to-date, but ideally without any work on our part, so we automated it.
The goals are:
– Have complete and up-to-date documentation of our APIs and up-to-date code samples in Confluence
– Notify stakeholders (other teams) of any breaking changes before they go into production and give them a few days to prepare or let us know so we can delay the release

We document our APIs using Swagger, which gets us a good part of the way there.
We accomplished the second goal by doing the first one twice (instructions below): deployments to our Staging server publish documentation to one confluence section, which stakeholders can subscribe to and get a diff whenever we update the page (again we don’t have to do this), and then our Production deployment publishes documentation to the production section on confluence. We also use semantic versioning for our APIs, which give our stakeholders a really quick idea of what we intend with the release.

Publishing release notes to TFS/VSTS Wiki during Release

2 min read As part of our process we create PBIs (work items) describing what needs to be done, and then during commit, our commit messages describe what we actually changed. During a release we need to keep track of this information and inform stakeholders as to what changed. This used to be fairly time-consuming step in which we had to gather information from the PBIs and commit messages and write up what we’re releasing. We managed to automate it to the point where all the information is linked cleanly into one page per release, with each work item linked directly, which allows someone to quickly get additional context.