Secret ingredients to quality software

Rules to Better DevOps - 24 Rules

If you still need help, visit our DevOps consulting page and book in a consultant.

Learn more about Scrum with Azure DevOps.

  1. Do you know what the goal of DevOps is?

    You should know what's going on with your errors and usage.

    The goal should be:

    A client calls and says: "I'm having problems with your software."

    Your answer: "Yes I know. Each morning we check the health of the app and we already saw a new exception. So I already have an engineer working on it."

    Take this survey to find out your DevOps index.

  2. Before you begin your journey into DevOps, you should assess yourself and see where your project is at and where you can improve.

    Take this survey to find out your DevOps index.

    DevOps Survey
    Figure: DevOps Survey form

    If you prefer you can download and print this survey in PDF.

    quiz devops
    Figure: DevOps Survey PDF

  3. Once you’ve identified the manual processes in Stage 1, you can start looking at automation. The best tool for build and release automation is Azure DevOps.

    See Rules to Better Continuous Deployments with TFS.

    2020 03 23 14 08 39
    Figure: In Azure DevOps you can automate application deployment to a staging environment and automatically run tests before deploying to production

  4. Now that your team is spending less time deploying the application, you’ve got more time to improve other aspects of the application, but first you need to know what to improve.

    Here are a few easy things to gather metrics on:

    Application Logging (Exceptions)

    See how many errors are being produced, aim to reduce this as the produce matures:

    But it's not only exceptions you should be looking at but also how your users are using the application, so you can see where you should invest your time:

    Application Metrics

    Application/Server performance – track how your code is running in production, that way you can tell if you need to provision more servers or increase hardware specs to keep up with demand

    2020 03 24 15 27 26
    Figure: Application Insights gives you information about how things are running and whether there are detected abnormalities in the telemetry

    2020 03 24 15 27 45
    Figure: Azure can render the Application Insights data on a nice dashboard so you can get a high level view of your application

    2020 03 24 15 28 22
    Figure: App Center can let you monitor app install stats, usage and errors from phones just like an app running in Azure

    Process Metrics

    Collecting stats about the application isn't enough, you also need to be able to measure the time spent in the processes used to develop and maintain the application. You should keep an eye on and measure:

    • Sprint Velocity
    • Time spent in testing
    • Time spent deploying
    • Time spent getting a new developer up to speed
    • Time spent in Scrum ceremonies
    • Time taken for a bug to be fixed and deployed to production

    Code Metrics

    The last set of metrics you should be looking at revolves around the code and how maintainable it is. You can use tools like:

  5. Now that you’ve got the numbers, you can then make decisions on what needs improvement and go through the DevOps cycle again.

    Here are some examples:

    • For exceptions, review your exception log (ELMAH, RayGun, HockeyApp)

      • Add the important ones onto your backlog for prioritization
      • Add an ignore to the exceptions you don't care about to reduce the noise (e.g. 404 errors)
      • You can do this as the exceptions appear, or prior to doing your Sprint Review as part of the backlog grooming
      • You don't have to get the exception log down to 0, just action the important ones and aim to reduce the noise so that the log is still useful
    • For code quality, add getting Code Auditor and ReSharper to 0 on files you’ve changed to your Definition of Done
    • For code quality, add SonarQube and identify your technical debt and track it improve processes
    • For application/server performance, add automated load tests, add code to auto scale up on Azure
    • For application usage, concentrate on features that get used the most and improve and streamline those features
  6. Do you evaluate the processes?

    Often an incorrect process is the main source of problems. Developers should be able to focus on what is important for the project rather than getting stuck on things that cause them to spin their wheels.

    1. Are devs getting bogged down in the UI?
    2. Do you have continuous integration and deployment?
    3. Do you have a Schema Master?
    4. Do you have a DevOps Master?
    5. Do you have a Scrum Master?

    Note: Anyway keep this brief since it is out of scope. If this step is problematic, there are likely other things you may need to discuss with the developers about improving their process. For example, are they using Test Driven Development, or are they checking in regularly, but all this and more should be saved for the Team & Process Review.

  7. Do you know how DevOps fits in with Scrum?

    DevOps and Scrum compliment each other very well. Scrum is about inspecting and adapting with the help of the Scrum ceremonies (Standup, Review, Planning and Retro). With DevOps it's all about Building, Measuring and Improving with the help of tools and automation.

    2016 06 08 14 33 24
    Figure: Traditional Scrum Process

    2016 06 08 14 30 33
    Figure: Scrum with DevOps

    With DevOps, we add tools to help us automate slow process like build and deployment then add metrics to give us numbers to help quantify our processes. Then we gather the metrics and figure out what can be done to improve.

    For example with Exception Handling, you may be using a tool like or Elmah and have 100s of errors logged in them. So what do you do with these errors? You can:

    1. Add each one to your backlog
    2. Add a task to each sprint to "Get exceptions to 0"

    The problem with the above is that not all exceptions are equal, and most of the time they are not more important than the planned PBIs being worked on. No developers like working a whole sprint just looking at exceptions. What should happen is:

    1. Have the exceptions visible in your development process (i.e. using Slack, adding as something to check before Sprint Planning)
    2. Triage the exceptions, either add them to the backlog if they are urgent and important
    3. Add ignore filters to the exception logging tool to ignore errors you don't care about (e.g. 404s)
    4. Prioritize the exceptions on the backlog

    The goal here is to make sure you're not missing important and to reduce the noise. You want these tools to help support your efforts and make your more productive and not just be another time sink.

  8. Do you have a DevOps Checklist?

    DevOps (Developers and IT Operations) is a phrase used to describe the relationship and/or communication between Developers and IT Operations.

    A DevOps checklist is a simple document that allows development teams to note all of the tasks related to monitoring and application life cycle along with their quality metrics and place them into one of three categories:

    1. Always Tasks Always Tasks are tasks that should be performed before the start of a new PBI.
    2. Daily Tasks Tasks that are performed at the start of each day.
    3. End of Sprint Tasks Tasks that are performed at the end of each sprint.

    Basic Action / Task Format

    Actions or Tasks follow a basic format of: Action / Task Name | Where the task can be performed | Quality Metric

    Action Table

    Figure: Good Example of a Basic Action Table format

  9. Knowing the holistic health of your application is important once it has been deployed into production. Getting feedback on your Availability, errors, performance, and usage is an important part of DevOps.We recommend using Application Insights, as getting it set up and running is quick, simple and relatively painless.

    Application Insights will tell you if your application goes down or runs slowly under load. If there are any uncaught exceptions, you'll be able to drill into the code to pinpoint the problem. You can also find out what your users are doing with the application so that you can tune it to their needs in each development cycle.

    Google analytics
    Figure: When developing a public website, you wouldn't deploy without Google Analytics to track metrics about user activity.

    2020 03 24 15 27 26
    Figure: For similar reasons, you shouldn't deploy a web application without metric tracking on performance and exceptions

    1. You need a portal for your app
    2. You need to know spikes are dangerous
    3. You need to monitor:

      1. Errors
      2. Performance
      3. Usage

    r437355 2104314
    Figure: Spikes on an Echidna are dangerous

    sockeye daily count
    Figure: Spikes on a graph are dangerous

    To add Application Insights to your application, make sure you follow the rule Do you know how to set up Application Insights?

    Can't use Application Insights? Check out the following rule Do you use the best exception handling library ?

  10. You've set up your Application Insights as per the rule 'Do you know how to set up Application Insights.

    Your daily failed requests are down to zero & You've tightened up any major performance problems.

    Now you will discover that understanding your users' usage within your app is child's play.

    The Application Insights provides devs with two different levels of usage tracking. The first is provided out of the box, made up of the user, session, and page view data. However, it is more useful to set up custom telemetry, which enables you to track users effectively as they move through your app.

    usage 1
    Figure: The most frequent event is someone filling out their timesheet

    It is very straightforward to add these to an application by adding a few lines of code to the hot points of your app. Follow Application Insights API for custom events and metrics to learn more.

    Feel constricted by the Application Insights custom events blade? Then you can export your data and display it in PowerBI in a number of interesting ways.

    Sugarlearning PowerBi
    Figure: Power BI creates an easy to use and in-depth dashboard for viewing the health of the application

    Previously we would have had to perform a complicated set up to allow Application Insights and Power BI to communicate. Follow How to connect Application Insights to Power BI via Azure Stream Analytic to learn more. Now it is as easy as adding the Application Insights content pack.

    Figure: Content packs make it simple to interact and pull data from third-party services

  11. Once you have set up your Application Insights as per the rule 'Do you know how to set up Application Insights' and you have your daily failed requests down to zero, you can start looking for performance problems. You will discover that uncovering your performance related problems are relatively straightforward.

    The main focus of the first blade is the 'Overview timeline' chart, which gives you a birds eye view of the health of your application.

    performance 1
    Figure: There are 3 spikes to investigate (one on each graph), but which is the most important? Hint: look at the scales!

    Developers can see the following insights:

    • Number of requests to the server and how many have failed (First blue graph)
    • The breakdown of your page load times (Green Graph)
    • How the application is scaling under different load types over a given period
    • When your key usage peaks occur

    Always investigate the spikes first, notice how the two blue ones line up? That should be investigated, however, notice that the green peak is actually at 4 hours. This is definitely the first thing we'll look at.

    performance 2
    Figure: The 'Average of Browser page load time by URL base' graph will highlight the slowest page.

    As we can see that a single request took four hours in the 'Average of Browser page load time by URL base' graph, it is important to examine this request.

    It would be nice to see the prior week for comparison, however, we're unable to in this section.

    performance 3
    Figure: In this case, the user agent string gives away the cause, Baidu (a Chinese search engine) got stuck and failed to index the page.

    At this point, we'll create a PBI to investigate the problem and fix it.

    (Suggestion to Microsoft, please allow annotating the graph to say we've investigated the spike)

    The other spike which requires investigation is in the server response times. To investigate it, click on the blue spike. This will open the Server response blade that allows you to compare the current server performance metrics to the previous weeks.

    performance 4
    Figure: In this case, the most important detail to action is the Get Healthcheck issue. Now you should be able to optimise the slowest pages

    In this view, we find performance related issues when the usage graph shows similarities to the previous week but the response times are higher. When this occurs, click and drag on the timeline to select the spike and then click the magnifying glass to ‘zoom in’. This will reload the ‘Average of Server response time by Operation name’ graph with only data for the selected period.

    Looking beyond the Average Response Times

    High average response times are easy to find and indicate an endpoint that is usually slow - so this is a good metric to start with. But sometimes a low average value can contain many successful fast requests hiding a few much slower requests.

    Application insights plots out the distribution of response time values allowing potential issues to be spotted.

    distribution **Figure: this distribution graph shows that under an average value of 54.9ms, 99% of requests were under 23ms but there were a few requests taking up to 32 seconds! **

  12. Application Insights can provide an overwhelming amount of errors in your web application, so use just-in-time bug processing to handle them.

    The goal is to each morning check your web application's dashboard and find zero errors. However, what happens if there are multiple errors? Don't panic, follow this process to improve your application's health.

    App Insights Failures
    Figure: Every morning developers check Application Insights for errors

    Once you have found an exception you can drill down into it to discover more context around what was happening. You can find out the user's browser details, what page they tried to access, as well as the stack trace (Tip: make sure you follow the rule on How to set up Application Insights to enhance the stack trace).

    App Insights Failures drilldown
    Figure: Drilling down into an exception to discover more.

    It's easy to be overwhelmed by all these issues, so don't create a bug for each issue or even the top 5 issues. Simply create one bug for the most critical issue. Reproduce, fix and close the bug then you can move onto the next one and repeat. This is just-in-time bug processing and will move your application towards better health one step at a time.

    20 08 2014 12 04 31 PM compressor
    Figure: Bad example - creating all the bugs

    20 08 2014 12 06 16 PM compressor
    Figure: Good example - create the first bug (unfortunately bug has to be created manually)

  13. Do you know how to handle errors in Raygun?

    Your team should always be ensuring that the health of the application is continually improving.

    The best way to do that is to check the exceptions that are being logged in the production application. Every morning, fix the most serious bug logged over the last week. After it is fixed then email yesterday's application health to the Product Owner.

    There's traditional error logging software like Log4Net or Elmah, but they just give you a wall of errors that are duplicated and don't give you the ability to mark anything as complete. You'll need to manually clear out the errors and move them into your task tracking system (Azure DevOps/

    This is where RayGun or Application Insights comes into the picture. RayGun gives you the following features:

    • Grouping exceptions
    • Ignoring/filtering exceptions
    • Triaging exceptions (mark them as resolved)
    • Integrations to TFS/ to create a Bug, Slack
    • Tracking the exceptions to a deployment
    • See which errors are occurring the most often

    Figure: Bad Example - Elmah gives you a wall of exceptions and no way to flag exceptions as completed

    Figure: Email with Raygun application health report

  14. Do you do exploratory testing?

    Use Microsoft's Exploratory Testing - Test & Feedback extension - to perform exploratory tests on web apps directly from the browser.

    Capture screenshots, annotate them and submit bugs as you explore your web app - all directly from Chrome (or Firefox) browser. Test on any platform (Windows, Mac or Linux), on different devices. No need for predefined test cases or test steps. Track your bugs in the cloud with Azure DevOps.

    Video: Ravi walks Adam through the exploratory testing extension - You can also watch on SSW TV

    Video: Ravi Shanker and Adam Cogan talk about the test improvements in Azure DevOps and the Chrome Test & Feedback extension - You can also watch on SSW TV

    1. Go to Visual Studio Marketplace and install "Test & Feedback".

    exploratory test extension install
    Figure: Microsoft Test & Feedback (was Exploratory Testing) extension

    1. Click "Add to Chrome" to add the extension to the browser on your computer.

    exploratory test extension add
    Figure: Chrome Web Store page for Test & Feedback extension

    1. Go to Chrome.
    2. Start a session by clicking on the Chrome extension and then click start a session.

    exploratory test extension icon
    Figure: Chrome extension icon

    exploratory test extension start
    Figure: Test & Feedback start session button

    1. Upload the screenshot to a PBI.

    pbi screenshot
    Figure: PBI in Azure DevOps showing the screenshot

    More info: Azure DevOps - Explore work items with the Test & Feedback extension

  15. When reporting bugs and giving product feedback, it is essential that you are as descriptive as possible.

    This will save the both you and the developer time and frustration in the long run.

    Make sure you always explain and give as many details as you can of how you got an error or a bad experience. Detailed and useful descriptions can make finding the solution quicker and easier.

    For bugs, the goal is to include enough details so the developer can easily reproduce the error to find out what the problem is.

    For suggested features it is best to:

    1. Draft your suggestion
    2. Call the Product Owner sharing screens, then add “checked by XXX”
    3. When using a backlog, create an Issue/PBI and @mention relevant people (they should get an email)

      If there is no backlog and an automatic nicely formatted email, you may send all the text and details via a normal email

    Try to have one issue/PBI/email per bug/suggestion, but if the bugs/suggestions are related or very small, then you may group them together in a single email.

    Figure: Bad Example - This email isn't going to help the developer much - it is vague, has no screen capture or other details to help reproducing the error

    Figure: Good Example - This email includes the product name and version, the category of the issue (BUG), a screen capture, and informs the user's system

    When possible, a great template to follow is the Functional Bug template from the ASP.NET open-source project. Spending time to provide as much detail as possible, by ensuring you have the 3 critical components:

    • Steps to reproduce,
    • Expected outcome, and
    • Actual outcome

    Figure: Bad example - Lack of details

    Figure: Good example - We can easily identify more the one way to improve the UX and there's a clear suggestion to action

    Videos can make things extra clear

    Better than a good description is a screen recording. This should be followed for a more detailed report. Use Snagit or Camtasia to record your screen.

    Figure: Good example - Recording bug reports in a video can make the issue clearer to see

    Figure: Good example - Giving feature requests via video

    Should you send this to the Product Owner or the Tech Lead?

    It depends on the team, but often the Product Owner is busy. If you know the Tech Lead and your suggestion is obviously a good one, then you should email the Tech Leader and Cc the Product Owner. The Product Owner can always reply if they don’t like the suggestion.

    For a bug email:

    To: Tech Lead
    Cc: Product Owner
    Subject: Bug - xxx (or use PBI @mention)

    For a new feature email:

    To: Tech Lead
    Cc: Product Owner
    Subject: Suggestion - xxx (or use PBI @mention)

    Note: You may have a group email such as, You would only Cc this email when a greater visibility is required.

    Use emojis and prefixes for PBI/Issues titles, or email subjects

    When you create a bug/suggestion to a backlog, it's a good idea to add emoji in the title. Not only does it look nicer, but people can look at the item and take in the necessary information quickly.

    This means that anyone looking at the backlog can glean its nature at a glance, rather than having to read each item to know what category it is (5 bugs, 2 features, etc). Examples:

    • 🐛 Bug - Calendar is not showing on iOS devices
    • ✨ Feature - Add 'Back to menu' item to top navigation

    Check out the rule on which emojis to use in Scrum.

    Tip: GitHub Issue Templates can help you with that.

  16. Do you use the best Code Analysis tools?

    Whenever you are writing code, you should always make sure it conforms to your team's standards. If everyone is following the same set of rules; someone else’s code will look more familiar and more like your code - ultimately easier to work with.

    No matter how good a coder you are, you will always miss things from time to time, so it's a really good idea to have a tool that automatically scans your code and reports on what you need to change in order to improve it.

    Visual Studio has a great Code Analysis tool to help you look for problems in your code. Combine this with Jetbrains' ReSharper and your code will be smell free.

    The levels of protection are:

    Figure: You wouldn't play cricket without protective gear and you shouldn't code without protective tools

    Level 1

    Get ReSharper to green on each file you touch. You want the files you work on to be left better than when you started. See Do you follow the boyscout rule?

    Tip: You can run through a file and tidy it very quickly if you know two great keyboard shortcuts:

    • Alt + [Page Down/Page Up] : Next/Previous Resharper Error / Warning
    • Alt + Enter: Smart refactoring suggestions

    48bc81 image001
    Figure: ReSharper will show Orange when it detects that there is code that could be improved

    Figure: ReSharper will show green when all code is tidy

    Level 2

    Is to use Code Auditor.

    Figure: Code Auditor shows a lot of warnings in this test project

    Note: Document any rules you've turned off.

    Level 3

    Is to use Link Auditor.

    Note: Document any rules you've turned off.

    Level 4

    Is to use StyleCop to check that your code has consistent style and formatting.

    Figure: StyleCop shows a lot of warnings in this test project

    Level 5

    Run Code Analysis (was FxCop) with the default settings or ReSharper with Code Analysis turned on

    Figure: Run Code Analysis in Visual Studio

    Figure: The Code Analysis results indicate there are 17 items that need fixing

    Level 6

    Ratchet up your Code Analysis Rules until you get to 'Microsoft All Rules'

    Figure: Start with the Minimum Recommended Rules, and then ratched up.

    Level 7

    Is to document any rules you've turned off.

    All of these rules allow you to disable rules that you're not concerned about. There's nothing wrong with disabling rules you don't want checked, but you should make it clear to developers why those rules were removed.

    Create a GlobalSuppressions.cs file in your project with the rules that have been turned off and why.

    suppressions file
    Figure: The suppressions file tells Code Analysis which rules it should disable for specific code blocks

    More Information: Do you make instructions at the beginning of a project and improve them gradually? and

    Level 8

    The gold standard is to useSonarQube, which gives you the code analysis that the previous levels give you as wells as the ability to analyze technical debt and to see which code changes had the most impact to technical debt

    2016 06 08 12 59 38
    Figure: SonarQube workflow with Visual Studio and Azure DevOps

    2016 06 08 12 59 53
    Figure: SonarQube gives you the changes in code analysis results between each check-in

  17. Do you look for Code Coverage?

    Code Coverage shows how much of your code is covered by tests and can be a useful tool for showing how effective your unit testing strategy is. However, it should be looked at with caution.

    • You should focus on *quality* not *quantity* of tests.
    • You should write tests for fragile code first and not waste time testing trivial methods
    • Remember the 80-20 rule - a very high-test coverage is a noble goal but there are diminishing returns.
    • If you're modifying code, write the test first, then change the code, then run the test to make sure it passes (AKA red-green-refactor).
    • You should run your tests regularly (see Do you follow a Test Driven Process). Ideally, they'll be part of your build (see Do you know the minimum builds to create for your project?

    Figure: Code Coverage metrics in Visual Studio. This solution has a very high code coverage percentage (around 80% on average)

    Tip: Do you use Live Unit Testing to see code coverage?

  18. Do you use Slack as part of your DevOps?

    Figure: See how Slack can be setup to improve your Devops

    With all these different tools being used to collect information in your application, a developer will frequently need to visit many different sites to get information like:

    • Was the last build successful?
    • What version is in production?
    • What errors are being triggered on the app?
    • Is the server running slow?
    • What is James working on?

    This is where a tool like Slack comes in handy. It can help your team aggregate this information from many separate sources into one dedicated channel for your project. The other benefits also include a new team member instantly having access to the full history of the channel as well so no conversations are lost.

    At SSW we integrate Slack with:

    • Octopus Deploy
    • TeamCity
    • Visual Studio

    Even better, you can create bots in slack to manage things like deployments and updating release notes.

    2016 06 06 11 22 03
    Good example - One centralized location for team chat, deployment issues, exceptions and TFS changes

  19. (Before you configure continuous deployment) You need to ensure that the code that you have on the server compiles. A successful CI build without deployment lets you know the solution will compile.

    ci build 1
    Figure: The Build definition name should include the project name. The reason for this is that builds for all solutions are placed in the same folder, and including the build name makes the Build Drop folder organised

    ci build 2
    Figure: On the Trigger tab choose Continuous Integration. This ensures that each check-in results in a build

    ci build 3
    Figure: On the Workspace tab you need to include all source control folders that are required for the build

    ci build 4
    Figure: Enter the path to your Drop Folder (where you drop your builds)

    ci build 5
    Figure: Choose the Default Build template and enter the DeployOnBuild argument to the MSBuild Arguments parameter of the build template

    ci build 6
    Figure: Queue a build, to ensure our CI build is working correctly

    ci build 7
    Figure: Before we setup continuous deployment it is important to get a successful basic CI build

  20. TFS and Windows Azure work wonderfully together. It only takes a minute to configure continuous deployment from Visual Studio Online ( to a Windows Azure Web Site or Cloud Service.

    This is by far the most simple method to achieve continuous deployment of your websites to Azure.But, if your application is more complicated, or you need to run UI tests as part of your deployment, you should be using Octopus Deploy instead according to the Do you use the best deployment tool rule.

    integrate source control
    Figure: Setting up deployment from source control is simple from within the Azure portal

    TFS Deployment
    Figure: Deployment is available from a number of different source control repositories

    Suggestion to Microsoft: We hope this functionality comes to on-premise TFS and IIS configurations in the next version.

  21. When a new developer joins a project, there is often a sea of information that they need to learn right away to be productive. This includes things like who the Product Owner and Scrum Master are, where the backlog is, where staging and production environments are, etc.

    Make it easy for the new developer by putting all this information in a central location like the Visual Studio dashboard.

    Note: As of October 2021, this feature is missing in GitHub Projects.


    2016 06 06 8 00 55
    Figure: Bad Example - Don't stick with the default dashboard, it's almost useless

    2016 06 06 9 15 14
    Figure: Good Example - This dashboard contains all the information a new team member would need to get started

    The dashboard should contain:

    1. Who the Product Owner is and who the Scrum Master is
    2. The Definition of Ready and the Definition of Done
    3. When the daily standups occur and when the next sprint review is scheduled
    4. The current sprint backlog
    5. Show the current build status
    6. Show links to:

      • Staging environment
      • Production environment
      • Any other external service used by the project e.g. Octopus Deploy, Application Insights, RayGun, Elmah, Slack

    Your solution should also contain the standard _Instructions.docx to your solution file for additional details on getting the project up and running in Visual Studio.

    For particularly large and complex projects, you can use an induction tool like SugarLearning to create a course for getting up to speed with the project.

    2016 06 06 7 18 43
    Figure: SugarLearning induction tool

  22. Do you Continuously Deploy?

    Continuous deployment is a set of processes and systems in place where every change is proven to be deployable to production and then deployed to production. E.g. DB migrations, code changes, metadata changes, scripts, etc. 

    At minimum teams needs to ensure that (a) All changes are sanitized by an automated continuous deployment pipeline (b) changes at end of each sprint are deployed to production. 

    View more detailed rules at Rules to Better Continuous Deployment with TFS

  23. Do you use the best deployment tool?

    Often, deployment is either done manually or as part of the build process. But deployment is a completely different step in your lifecycle. It's important that deployment is automated, but done separately from the build process.

    There are two main reasons you should separate your deployment from your build process:

    1. You're not dependent on your servers for your build to succeed. Similarly, if you need to change deployment locations, or add or remove servers, you don't have to edit your build definition and risk breaking your build.
    2. You want to make sure you're deploying the *same* (tested) build of your software to each environment. If your deployment step is part of your build step, you may be rebuilding each time you deploy to a new environment.

    The best tool for deployments is Octopus Deploy.

    Figure: Good Example - SSW uses Octopus Deploy to deploy Sugar Learning

    Octopus Deploy allows you to package your projects in Nuget packages, publish them to the Octopus server, and deploy the package to your configured environments. Advanced users can also perform other tasks as part of a deployment like running integration and smoke tests, or notifying third-party services of a successful deployment.

    Version 2.6 of Octopus Deploy introduced the ability to create a new release and trigger a deployment when a new package is pushed to the Octopus server. Combined with Octopack, this makes continuous integration very easy from Team Foundation Server.

    What if you need to sync files manually?

    Then you should use an FTP client, which allows you to update files you have changed. FTP Sync and Beyond Compare are recommended as they compare all the files on the web server to a directory on a local machine, including date updated, file size and report which file is newer and what files will be overridden by uploading or downloading. you should only make changes on the local machine, so we can always upload files from the local machine to the web server.

    This process allows you to keep a local copy of your live website on your machine - a great backup as a side effect.

    Whenever you make changes on the website, as soon as they are approved they will be uploaded. You should tick the box that says "sync sub-folders", but when you click sync be careful to check any files that may be marked for a reverse sync. You should reverse the direction on these files. For most general editing tasks, changes should be uploaded as soon as they are done. Don't leave it until the end of the day. You won't be able to remember what pages you've changed. And when you upload a file, you should sync EVERY file in that directory. It's highly likely that un-synced files have been changed by someone, and forgotten to be uploaded. And make sure that deleted folders in the local server are deleted in the remote server.


    If you are working on some files that you do not want to sync then put a _DoNotSyncFilesInThisFolder_XX.txt file in the folder. (Replace XX with your initials.) So if you see files that are to be synced (and you don't see this file) then find out who did it and tell them to sync. The reason you have this TXT file is so that people don't keep telling the web

    NOTE: Immediately before deployment of an ASP.NET application with FTP Sync, you should ensure that the application compiles - otherwise it will not work correctly on the destination server (even though it still works on the development server).

  24. Gated checkins are used to stop developers from checking in bad code and breaking the build.

    This does not contribute to high functioning teams, and instead masks, or even creates dysfunction.

    In the retro the team decides to turn gated checkins on because Jonny and Sue keep breaking the build.

    The build doesn’t get broken any more, because Jonny and Sue now have to fix their code before they check it in.

    This doesn’t mean that Jonny and Sue are writing better code, it just means that they are not checking in code that breaks the build.

    Gated checkins will not improve their skill level, change their attitude or improve the quality of their code.

    The development ninjas on the team are proud of their code, and check in several times per day. Because the gated checkin takes 10 minutes their workflow is impacted.

    They resent Jonny and Sue for having to work this way.

    Gated Checkins mask the dysfunction on the team, and introduce impediments to the high performers.

    Bad Example – Gated Checkins mask dysfunction

    In the retro the team discusses the fact that the build is often broken. After a round table discussion about becoming better programmers and building better quality software, the team decides to the following guidelines:

    1. The team will all run build notifications so that everyone knows when, and by whom the build is broken.
    2. If someone needs help with solving a problem, they are going to feel good about asking for help early, and learning something new in the answer.
    3. If someone is asked for help, they will gladly share their knowledge to ensure that the quality of the project is maintained ,and the team help each other to become better developers.
    4. Before checking in, the devs will compile and run all tests. **
    5. If someone checks in and does break the build, they will call out to all members of the team that the build is broken so that no-one gets latest. They will fix the build IMMEDIATELY, and then call out again when it is fixed. (Some teams have a rule that if you break the build three times you have to shout coffee / lunch).
    6. The team agrees that you don’t go home if the build isn’t green. If it comes to the end of the day and you are not sure your code will not break the build – do not checkin. Create a shelveset and resolve the issue properly the next day.

    If you have checked in, the build is broken, and you cannot fix it before going home, you must email all devs on the team, and the product owner with an explanation.

    1. The status of the build is reviewed in every daily scrum.

    Good Example – The whole team should be constantly aware and invested in the status of the build, the quality of the software and in encouraging each other to better developers.** I actually don’t follow this rule when working on small teams of awesome devs, who write code against tests and checkin frequently.

    Instead I encourage the process to be:

    • checkin 4-5 times a day
    • write lots of tests
    • if the tests that you are working against pass- checkin and let the build server do a full compile and run all the tests
    • if you have broken the build, call it out, fix it immediately and then call it out again.

    This is the most productive way for small teams of awesome developers to produce great code… and it's fun !

We open source. Powered by GitHub