Monday, October 17, 2016

Visual Studio Team Services Git your build face on

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


See "Enable Build Level Permissions" below if you get the following error
##[error]bash: /dev/tty: No such device or address 

Let VSTS Builds Update GIT Repository

Some builds may need to update a GIT repository upon build success.  This could be to merge with another branch, add test results or some other process. This change occurs at the VS Team Project level.
The build account must have GIT update permissions.This is a repository level control that must be set in the VS TS Control panel. 

This can be applied at the repository or branch level.  The picture to the right shows where to click to set this at the repository level.

All branches inherit permissions set at this level

Access control attributes "Branch creation" and "Contribute" have default values of "Not Set".  Change these to "Allow".

Access control attributes "Read" and "Tag Creation" have default values of "Inherited allow".  That level is sufficient for our needs.  Do not change them.


Enabling GIT Build Integration

Builds are bound to code repositories.  Builds must be configured to point to the correct Git repository and branch. This change is made on each build that requires Git access. This must be done for every build that is triggered by check-in changes.

Configure the Repository on the Build -> Definitions tab tied to he build itself.  This is not done on the project Control Panel.

Triggering Builds on Changes

Continuous Integration builds trigger whenever the source code repository is updated.  This must be done for every build that is triggered by check-in changes.

Configure build triggers on the Triggers pane of the Build -> Definitions tab tied to the build itself.  This is not done on the project Control Panel.

Provide Credentials for GIT Updates

Some builds may need to update a GIT repository upon build success.  This could be to merge with another branch, add test results or some other process.

The build account must have GIT update permissions as described above.

The build itself must present the build account's OAuth token to GIT when running any GIT update commands, usually "GIT push"

Enable OAuth tokens in scripts on the Definitions -> Option pane.

This error means you have not enabled credentials propagation.  You must enable the OATH Token.
##[error]bash: /dev/tty: No such device or address


The following web pages or blog articles were helpful while learning this information

Created 2016 Oct 16

Tuesday, October 4, 2016

Classifying your return codes

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 simple proposed of categories

HTTP Code CategoryRemediation OwnerRemediation
SuccessEveryoneApplication or n/a
Business ErrorBusinessManual process or Application rule
Technical ErrorIT / TechnologyManual
Embedded RedirectIT / TechnologyApplication Library
NACK / RetryIT / TechnologyLibrary and/or delayed retry mechanism

Asynchronous Messaging.

You can create the same types of categories for message driven systems.  They can post return codes to reply / response queus or to event log capture.

Proposed Return Code Categories

Map each response code to one of the categories.  Make your application return the correct code for each service it provides. Implement the correct behavior for each service it invokes. The following is a sample list of proposed HTTP return code categories.

HTTP CodeReturn Code DescriptionDefault Contract Behavior
100ContinueTechnical Error
101Switching protocolTechnical Error
203Non-Authorative InformationSuccess
204No ContentSuccess
206Partial ContentSuccess
207Partial SuccessBusiness Error
300Multiple ChoicesTechnical Error
301Moved PermanentlyEmbedded Redirect
302FoundEmbedded Redirect
303See OtherEmbedded Redirect
304Not ModifiedTechnical Error
305Use ProxyTechnical Error
306UnusedTechnical Error
307Temporary RedirectEmbedded Redirect
308Permanent RedirectEmbedded Redirect
400Bad RequestBusiness Error
401UnauthorizedTechnical Error
402Payment RequiredTechnical Error
403ForbiddenTechnical Error
404Not FoundTechnical Error
405Method Not AllowedTechnical Error
406Not AcceptableTechnical Error
407Proxy Auth RequiredTechnical Error
408Request TimeoutTechnical Error
409ConflictTechnical Error
410GoneTechnical Error
411Length RequiredTechnical Error
412Precondition FailedTechnical Error
413Request Entity Too LargeTechnical Error
414Request-URI Too LongTechnical Error
415Unsupported Media TypeTechnical Error
416Request Ranage Not SatisfyableTechnical Error
417Expectation FailedTechnical Error
500Internal Server ErrorNack / Retry
501Not ImplementedTechnical Error
502Bad GatewayTechnical Error
503Service UnavailableNack / Retry
504Gateway TimeoutNack / Retry
505HTTP Version Not SupportedTechnical Error
N/AFailed to Route?


blah blah and blah blah

Created 2016 Oct 04