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 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.