Blog de Joe Freeman

I starting this project trying to build and deploy the  ASP.NET Core   example application  first on my local box, then in Microsoft Azure via Web Deploy, Microsoft Azure via local Azure GIT integration and finally via Visual Studio Team Services (VSTS) via SCM integration. Deployment Types Local deployment into a local IIS is pretty straightforward. We won't talk about it here.  Remote web deployments are the legacy way of pushing Web applications to the (Azure) cloud that works with IDE, CI or command line. Compiled and static application artifacts that are then sent to the remote application servers via FTP.   The servers unpack the archive and deploys it. Remote SCM deployments are a relatively new and interesting way to support automated deployments and to support multiple branches with little work. The IDE or build system pushes source code to a monitored repository.  Azure (Kudu) monitors the source code repository, runs a build and deploys the resulting artifacts to

This page describes configuration settings required to enable GIT integration when building code in Visual Studio team Services.  It will show you how to Enable CI builds when a specific GIT repository and branch are updated Provide the CI build with permissions required to make changes to a GIT repository Provide the CI build with credentials required to make changes to a GIT repository This diagram shows how GIT and Visual Studio Team Services (VSTS) might be used to implement a CI build triggered on check-in that merges code into another branch and deploys it.  The actual deployment commands are out of scope for this document. The following changes must be made on the Repositories configuration at the Project (Team) level and on the affected individual build definitions. We first show project level configuration and then Build Definition  configuration. Let VSTS Builds Update GIT Repository Some builds may need to update a GIT repository upon build success.  This

Be explicit about your service behavior and service return codes.  REST is great but you need to understand the types of failures you can have.  Some may be actual failures.  Others may be successful service invocations with a failure to complete business operations because of business rules. Document the meaning, ownership, and handling behavior of your Service return codes.  Do not assume your partner teams and calling systems have any expectations or understanding beyond success and not-success .  Ask other teams, you  call,  for their Service return code documentation. Force them to document their expectations. Proposed Return Code Category Types Create response categories.  Determine the owner and expected behavior possibilities for each category for services you build.  The following is a basic categorization. HTTP Code Category Remediation Owner Remediation Success Everyone Application or none required Business Error Business Manual process or Application rule T

Victory has 100 fathers. No-one wants to recognize failure.     The Italian Job Developers and designers spend a fair amount of time creating API, streaming and service contracts.  The primary focus tends to be around happy path API invocation with a lot of discussion about the parameters and the data that is returned.   Teams seem to spend little time on the multitude of failure paths often avoiding any type of failure analysis and planning.  Plan ahead and learn what failure or partial failure looks like and how you will handle it. At the API level: Some groups standardize on  void  methods that throw Exceptions to declare errors. The list of possible exceptions and their causes is not documented.  Exceptions contain messages but no structured machine readable data. At the REST web service level: Some groups standardize on service return values other than 200  for errors. They do not document all of the HTTP return codes they can generate or their meanings.  API consumers are lef