CLI: Cloud Provider Auth (ON-HOLD)

[ianphil]

A good user story should be (I-N-V-E-S-T principle)

• Independent (from other user stories, allowing to realize them in any order);
• Negotiable (omit details that would freeze the story);
• Valuable (implementation delivers an increment of functionality, observable by and useful to users);
• Estimable (developers should be able to estimate its size relative to other stories);
• Sizable (implementation fits in one iteration – if it needs many to complete, it is an EPIC);
• Testable (user must be able to check the conditions of satisfaction).

Description

As a developer, I should be able to authenticate a cloud provider, so that I can run deployments.

Acceptance Criteria

Reference: [Done-Done Checklist] (https://github.com/Microsoft/code-with-engineering-playbook/blob/master/Engineering/BestPractices/DoneDone.md)

• The CLI allows me to select the service principal used for terraform deployments
• My .env is pre-filled by the CLI after selecting my service principal and storage account.
• Azure login similar pattern as azcli
• Extensible for other cloud providers

Also, here are a few points that need to be addressed:

1. Interface for provider login
2. Azure will be the only implementation

Resources

Technical Design Document
Mockups

Tasks

Stories are intended to be completed in a single sprint; if task breakdown creates addition work then team should discuss promoting the Story to an Epic.
Reference: [Minimal Valuable Slices] (https://github.com/Microsoft/code-with-engineering-playbook/blob/master/Engineering/BestPractices/MinimalSlices.md)

Reference: [How to Write Better Tasks] (http://agilebutpragmatic.blogspot.com/2012/04/splitting-story-into-tasks-how-to-write.html)

Assignee should break down work into tasks here

• Create a library for auth
• Create auth interface
• Implement Azure auth by interface
• Create tests