Global SDK Configuration Acceptance Criteria

As a software developer I need to provide a mechanism to set up the environment configuration so that values of the environment variables can be configured seamlessly for different environments like "Dev", "test", "production", etc.

The primary focus of this story is to provide the ability to set the right credential settings for the right environment

There are different services provided by the node sdk such as:

• service management
• storage
• blob
• table
• queue
• servicebus
• website management
• sql azure

The user can use the global configuration and helper methods to configure settings for a particular environment say: "production"

azure.configure("production", function(c) {
    c.storage({ account: 'teststorage', key: '123456476546874687=='});
});

Now, the user needs to access the dev environment for which the storage account and the access key are different.

Note: The below is a much lower priority scenario

The values of configuration parameters can be changed without restarting the application

azure.configure("dev", function(c) {
    c.storage({account: 'teststorage1', key: 'AAAAA123456476546874687=='});
});

These changes will be observed when creating new objects that use that configuration parameter; existing objects will continue to use the ones they were created with.

It also provides the concept of child configurations and lookup. Let us assume the following hierarchy of configurations.

                                              [Root]
                                                 |
                                                 |
                                 ---------------------------------
                                 |               |                |
                                 |               |                |
                               [Dev]           [Test]         [Production]
                                                 |
                                                 |
                                           ---------------
                                           |              |
                                           |              |
                                       [Inventory]      [Payroll]

NODE_ENV lets you select only one level below the root. If you need to select an environment below that then, you need to explicitly specify it.

var c = azure.config(Test)(Inventory);

NODE_ENV variable is set to Production.

process.env.NODE_ENV = 'Production';
azure.configure("Production", function (c)) {
    c.servicebus("settingone", "valueone");
    c.storage("ACCESS_KEY", "some value");
});
azure.configure("Test", function (c)) {
    c.servicebus("settingtwo", "valueone");
    c.storage("ACCESS_KEY", "some value");
    //creating a child configuration
    c.configure("East US", function(c2)) {
        c2.createBlobService("Access_key" "blah1");
    });
});

Inside the application if a particular setting is required for a specific environment, then it will look for the setting in the configuration. If it is not found then it will look in its parent and so forth until it reaches the Root. If it is not found in the Root then it searches for the Environment variables to set the value.

Precedence of connection string over storage account and access key

Talk about acceptance criteria.

1. Set the default (Root) configuration and do not provide any configuration settings. Verify that (Payroll)(Test) looks up the root and sets the values of credentials provided over there

2. Set the NODE_ENV to production. Create a blobservice. This blob service will use the credential settings provided for Production environment. Then change the NODE_ENV to Test. Now create a ServiceBus. This should use the settings of the Test envt.

3. Same environment but two storage accounts. One for tableservice and the other for servicebus

4. Specify a named environment and verify if its settings are set as default.

5. Provide connection string, storage account and access key. The connection string should take precedence over the account and the access key for creating a blob service