You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: connected-environment/common/build-and-run-in-k8s-cli.md
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
-
## Build and Run Code in Kubernetes
2
-
Let's run our code! In the terminal window, run this command from the **root code folder**, i.e. webfrontend:
1
+
## Build and run code in Kubernetes
2
+
Let's run our code! In the terminal window, run this command from the **root code folder**, webfrontend:
3
3
4
4
```cmd
5
5
vsce up
@@ -13,11 +13,11 @@ Keep an eye on the command's output, you'll notice several things as it progress
13
13
1. Assuming the above stages complete successfully, you should begin to see `stdout` (and `stderr`) output as the container starts up.
14
14
15
15
> [!Note]
16
-
> These steps will take longer the first time the `up` command is run - they are considerably shortened on subsequent runs.
16
+
> These steps will take longer the first time the `up` command is run, but subsequent runs should be quicker.
17
17
18
-
## Test the App
18
+
## Test the web app
19
19
Scan the console output for information about the public URL that was created by the `up` command. It will be in the form:
20
20
21
21
`Running at public URL: https://<servicename>-<environmentname>.vsce.io`
22
22
23
-
Open this URL in a browser window - or better yet, from a mobile device - and you should see the web app load! As the container executes, `stdout` and `stderr` output is streamed to the terminal window.
23
+
Open this URL in a browser window - or better yet, from a mobile device - and you should see the web app load. As the container executes, `stdout` and `stderr` output is streamed to the terminal window.
Copy file name to clipboardExpand all lines: connected-environment/common/create-env-cli.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
## Create a Kubernetes Development Environment in Azure
1
+
## Create a Kubernetes development environment in Azure
2
2
With Connected Environment, you can create Kubernetes-based environments that are fully managed by Azure and optimized for development. The command creates an environment named `mydevenvironment` in `eastus`. You'll need to enter a unique environment name.
## Ensure the Development Environment Was Successfully Created
2
-
In the previous section, we kicked off the `vsce env create` command to create a development environment in Azure. It takes several minutes to complete, so check back that it was successfully created. You can always check the environments you have access to, and their status, with this command: `vsce env list`.
1
+
## Ensure the development environment was successfully created
2
+
In the previous section, we kicked off the `vsce env create` command to create a development environment in Azure. It can take about 7 minutes to complete, so check back that it was successfully created. You can always check the environments you have access to, and their status, with this command: `vsce env list`.
Copy file name to clipboardExpand all lines: connected-environment/common/init-debug-assets-vscode.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
## Initialize Debug Assets with the VS Code Extension
1
+
## Initialize debug assets with the VS Code extension
2
2
We first need to configure our code project so VS Code will communicate with our development environment in Azure. The VS Code extension for Connected Environment provides a helper command to set up debug configuration.
3
3
4
4
Open the **Command Palette** (using the **View | Command Palette** menu), and use auto-complete to type and select this command: `Connected Environment: Create configuration files for connected development`.
Copy file name to clipboardExpand all lines: connected-environment/common/install-cli-and-vscode.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
## Install the Connected Environment CLI
2
-
There is minimal local machine setup required with Connected Environment. Most of your development environment's configuration will be in the cloud, making it easily shareable with others.
2
+
Connected Environment requires minimal local machine setup. Most of your development environment's configuration gets stored in the cloud, and is shareable with other users.
3
3
4
4
### Install on Mac
5
5
Download and install the Connected Environment CLI:
While you can use the Connected Environment CLI as a standalone tool, rich features like Kubernetes debugging are available for .NET Core and Node.js developers using VS Code.
20
20
21
21
1. If you don't have it, install [VS Code](https://code.visualstudio.com/Download).
So far we've run our application's code as if we were the only developer working on the app. In this section, we'll learn how Connected Environment streamlines team development by making it easy to:
1
+
So far we've run our application's code as if we were the only developer working on the app. In this section, we'll learn how Connected Environment streamlines team development:
2
2
* Enable a team of developers to work in the same development environment.
3
3
* Supports each developer iterating on their code in isolation and without fear of breaking others.
4
-
*Easily test code end-to-end, prior to code commit, without having to create mocks or simulate dependencies.
4
+
*Test code end-to-end, prior to code commit, without having to create mocks or simulate dependencies.
5
5
6
-
## Challenges with Developing Microservices
6
+
## Challenges with developing microservices
7
7
Our sample application isn't very complex at the moment. But in real-world development, challenges soon emerge as more services are added and the development team grows.
8
8
9
-
Picture yourself working on a service that interacts with tens of other services.
9
+
Picture yourself working on a service that interacts with dozens of other services.
10
10
11
-
1. It can become unrealistic to run everything locally for development. Your dev machine may simply not have enough resources to run the entire app; or maybe your app has endpoints that need to be publicly reachable (e.g. your app responds to a webhook from a SaaS app).
12
-
1. You can try to only run the services that you depend on, but this means you'd need know the full closure of dependencies (i.e. dependencies of dependencies). Or, it's simply a matter of not easily knowing how to build and run your dependencies because you didn't work on them.
13
-
1. Some developers resort to simulating, or mocking up, most of their service dependencies. This can help sometimes, but managing those mocks can soon take on its own development effort. Plus, this leads to your dev environment looking very different to production, and subtle bugs can creep in.
11
+
1. It can become unrealistic to run everything locally for development. Your dev machine may not have enough resources to run the entire app. Or, perhaps your app has endpoints that need to be publicly reachable (for example, your app responds to a webhook from a SaaS app).
12
+
1. You can try to only run the services that you depend on, but this means you'd need know the full closure of dependencies (for example, dependencies of dependencies). Or, it's a matter of not easily knowing how to build and run your dependencies because you didn't work on them.
13
+
1. Some developers resort to simulating, or mocking up, many of their service dependencies. This can help sometimes, but managing those mocks can soon take on its own development effort. Plus, this leads to your dev environment looking very different to production, and subtle bugs can creep in.
14
14
1. It follows that doing any type of end-to-end testing becomes difficult. Integration testing can only realistically happen post-commit, which means we see problems later in the development cycle.
15
15
16
16
17
17
18
18
19
-
## Work in a Shared Development Environment
20
-
With Connected Environment, you can easily set up a *shared* development environment in Azure. Each developer can focus on just their part of the application, and can iteratively develop *pre-commit code* in an environment that already contains all the other services and cloud resources that their scenarios depend on. Dependencies are always up to date, and developers are working in a way that mirrors production.
19
+
## Work in a shared development environment
20
+
With Connected Environment, you can set up a *shared* development environment in Azure. Each developer can focus on just their part of the application, and can iteratively develop *pre-commit code* in an environment that already contains all the other services and cloud resources that their scenarios depend on. Dependencies are always up to date, and developers are working in a way that mirrors production.
21
21
22
-
## Work in Your Own Space
23
-
As you develop code for your service, and before you're ready to check it in, code often won't be in a good state - you're still iteratively shaping it, testing it, and experimenting with solutions. Connected Environment provides the concept of a **space**, which allows you to work in isolation, and without the fear of breaking your team members.
22
+
## Work in your own space
23
+
As you develop code for your service, and before you're ready to check it in, code often won't be in a good state. You're still iteratively shaping it, testing it, and experimenting with solutions. Connected Environment provides the concept of a **space**, which allows you to work in isolation, and without the fear of breaking your team members.
24
24
25
25
> [!Note]
26
26
> Before you proceed, close all VS Code windows for both services, and then run `vsce up -d` in each of the service's root folders. (This is a Preview limitation.)
27
27
28
-
Now let's take a closer look at where the services are currently running. Run the `vsce list` command, and you'll see output similar to the following:
28
+
Let's take a closer look at where the services are currently running. Run the `vsce list` command, and you'll see output similar to the following:
webfrontend mainline webfrontend-0.1.0 80/TCP 1m ago https://webfrontend-contosodev.vsce.io
35
35
```
36
36
37
-
The Space column shows that both services are running in a space named `mainline`. Anyone who opens the public URL and navigates to the web app will invoke the code path we previously wrote that runs through both services. Now suppose we want to continue developing `mywebapi` - how can we do this and not interrupt other developers who are using the dev environment? To do that, we'll set up our own space.
37
+
The Space column shows that both services are running in a space named `mainline`. Anyone who opens the public URL and navigates to the web app will invoke the code path we previously wrote that runs through both services. Now suppose we want to continue developing `mywebapi`. How can we do this and not interrupt other developers who are using the dev environment? To do that, we'll set up our own space.
38
38
39
-
## Create a Space
39
+
## Create a space
40
40
To run our own version of `mywebapi` in a space other than `mainline`, we create our own space:
41
41
```
42
42
vsce space create --name scott
43
43
```
44
44
45
-
In the example above, I've used my name for the new space so that it is easily identifiable to my peers that that's the space I'm working in, but you can call it anything you'd like and be flexible about what it means, like 'sprint4' or 'demo'.
45
+
In the example above, I've used my name for the new space so that it is identifiable to my peers that that's the space I'm working in, but you can call it anything you'd like and be flexible about what it means, like 'sprint4' or 'demo'.
46
46
47
47
Run the `vsce space list` command to see a list of all the spaces in the dev environment. An asterisk (*) appears next to the currently selected space. In our case, the space named 'scott' was automatically selected when it was created. You can select another space at any time with the `vsce space select` command.
This built-in capability of Connected Environment enables you easily test code end-to-end in a shared evironment without requiring each developer to re-create the full stack of services in their space. Note that this routing requires propagation headers to be forwarded in your app code, as illustrated in the previous step of this guide.
13
+
This built-in capability of Connected Environment enables you test code end-to-end in a shared evironment without requiring each developer to re-create the full stack of services in their space. Note that this routing requires propagation headers to be forwarded in your app code, as illustrated in the previous step of this guide.
14
14
15
-
## Test Code Running in the 'Scott' Space
16
-
To test our new version of `mywebapi` in conjunction with `webfrontend`, open your browser to the public access point URL for webfrontend and navigate to the About page. You should see your new message displayed.
15
+
## Test code in a space
16
+
To test our new version of `mywebapi` in conjunction with `webfrontend`, open your browser to the public access point URL for webfrontend and go to the About page. You should see your new message displayed.
17
17
18
-
Now, remove the "scott-" part of the URL, and refresh the browser - you should see the old behavior (exhibited by the `mywebapi` version running in `mainline`).
18
+
Now, remove the "scott-" part of the URL, and refresh the browser. You should see the old behavior (exhibited by the `mywebapi` version running in `mainline`).
Copy file name to clipboardExpand all lines: connected-environment/common/vsce-init.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
-
## Initialize Code for Docker and Kubernetes Development
2
-
So far, we have a basic web app that can run locally - we'll now containerize it by creating assets that define the app's container and how it will deploy to Kubernetes. This is easy to do with Connected Environment:
1
+
## Initialize code for Docker and Kubernetes development
2
+
So far, we have a basic web app that can run locally. We'll now containerize it by creating assets that define the app's container and how it will deploy to Kubernetes. This is easy to do with Connected Environment:
3
3
4
4
1. Launch VS Code and open the `webfrontend` folder. (You can ignore any default prompts to add debug assets or restore the project.)
5
5
1. Open the Integrated Terminal in VS Code (using the **View | Integrated Terminal** menu).
0 commit comments