We often use GitHub to create a compare view, and list pull requests (PRs) for releases. However, GitHub limits the number of commits you...Documentation GitHub Git
This past year we’ve been on a DevOps journey. While we haven’t been in a state of stagnation or chaos as a team, we’ve identified areas where we could improve. We wanted to improve in areas that helped us work better as a team and deploy the best applications we can. We didn’t start our transformation with no practices or principles as a team. We’ve been doing continuous integration, continuous delivery, and pull requests using GitHub for quite some time. We weren’t starting from zero by any measure. But, over time we’ve identified areas in our processes where we can improve based on how we work as a team.
masterbranch to production and the
developmentbranch to our QA enviroment.
masterto our Development environment (replaces QA). At any point in time cut a release branch from
master, verify it is working and stable in our staging environment, and swap that into production.
We also found it more cost effective to group applications onto fewer app service plans. It can suffer from noisy neighbor issues, but at least we know all of the neighbors (since they’re all our own applications).
Basically we do very well as as team with the code items in a pull request, but there’s room for improvement for items that aren’t in pull requests.
Everyday we strive to make our systems more functional, reliable, and available. We’ll continue to improve and revise our infrastructure and processes as a team to better suit our workflow and help meet our goals. We expect the journey to continue into the future as we continue to refine and adjust what works best for our team.