Speed up development in Cloud Code for Cloud Shell

To speed up your local development in Cloud Code for Cloud Shell, take advantage of file sync and hot reloading, automatic deployment on save, and use Skaffold modules to develop portions of an application separately.

Enable Skaffold file sync and hot reloading

To improve the efficiency of your local development workflow and avoid having to rebuild, redeploy, and restart your pods, Skaffold supports copying changed files to a deployed container. This means that when you're making changes to static and source code files, you can see your changes take effect in seconds, making for an accelerated feedback loop.

For static files (like HTML and CSS files), this file copying behavior is called file syncing.

For source code files, this behavior is called as hot reloading and supports the following file types:

  • Go: *.go
  • Java: *.java, *.kt, *.scala, *.groovy, *.clj
  • NodeJS: *.js, *.mjs, *.coffee, *.litcoffee, *.json

With hot reloading configured, Skaffold detects changes to supported files and syncs these changes to the running container on your cluster. Changes to file types that don't support hot reloading trigger an image rebuild and pod restart.

Automatic file-syncing and hot reloading are enabled by default when you're working with Buildpacks as your preferred builder. For other builders like Docker, you can specify a sync section in your skaffold.yaml file for the artifact you're customizing.

Your sync setting can be one of (in order of preference):

  • auto: Skaffold automatically configures the sync. (only for Jib and Buildpacks artifacts.) This is the default for Buildpacks.
  • infer: The destinations for each changed file are inferred from the builder.
  • manual: You must specify the files in your local workspace and their destination in the running container.

The following sample sync section in a skaffold.yaml file specifies a manual sync to synchronize all /static-html HTML files to the static folder in a container:

build:
  artifacts:
    - image: gcr.io/k8s-skaffold/node-example
      context: node
      sync:
        manual:
          - src: 'static-html/*.html'
            dest: static

For a detailed look at file syncing and specifying sync rules, see the Skaffold guide on file sync.

Add new features when developing on Kubernetes

After setting up file sync and hot reloading, start an iteration cycle and add more features to your project. Your changes are deployed to your Kubernetes cluster without stopping and removing the deployment, manually building and tagging the image, or updating the cluster.

A standard iteration cycle resembles the following:

  1. Make a change in your project. For example, if using the Cloud Code Java Guestbook app, add a new endpoint to the FrontendController class as follows:

    1. Open the FrontendController.java file from src/main/java/cloudcode/guestbook/frontend and add the following:

      @RequestMapping("/greeting")
@ResponseBody
public String greeting(@RequestParam(value="name", defaultValue="World") String name) {
   return String.format("Hello from Kubernetes with IntelliJ, %s!", name);
}

    2. Add the necessary imports for the new annotations, RequestMapping and ResponseBody.

  2. Save your changes (Ctrl/Cmd+S) or build the project.

    You can watch the progress and deployment logs in the console window. After the changes are deployed, confirm the updates.

  3. To end the continuous development session, click the Stop icon.

    Cloud Code deletes all Kubernetes resources used for the development session.

Develop microservices applications using Skaffold configurations

When developing microservice applications, it can be useful to work on separate sections independently to simplify debugging and deployment.

You can develop and debug parts of your application independently by splitting your application into Skaffold modules. For example, the Bank of Anthos sample is an application containing ten microservices. The sample's skaffold.yaml file groups these services into five skaffold modules named setup, db, frontend, backend, and loadgenerator.

Define Skaffold modules and configuration dependencies

To define Skaffold modules and configuration dependencies:

  1. Open the project where you want to define the modules.

  2. Open the skaffold.yaml file.

  3. If your skaffold.yaml file has multiple configurations, to make a configuration a Skaffold module, specify the following line:

    metadata:
  name: MODULE_NAME_1

    For example, in the Bank of Anthos skaffold.yaml, the db module defines database deployments:

    apiVersion: skaffold/v3
kind: Config
metadata:
  name: db # module defining database deployments
requires:
- configs:
  - setup
build:
  artifacts:
  - image: accounts-db
    context: src/accounts-db
  - image: ledger-db
    context: src/ledger-db
manifests:
  rawYaml:
  - dev-kubernetes-manifests/accounts-db.yaml
  - dev-kubernetes-manifests/ledger-db.yaml
deploy:
  kubectl: {}

  4. For configurations that rely on another configuration being deployed before the current configuration can be deployed, you must add the config to your dependencies. To specify a config dependency, add a configs list to the requires section of your skaffold.yaml file.

    For example, the Bank of Anthos skaffold.yaml file includes the configuration dependency setup.

    To define a dependency, add the following to your skaffold.yaml file where DEPENDENCY_NAME is the name of your dependency.

    requires:
    - configs: DEPENDENCY_NAME

    Configurations listed this way can reference dependencies defined in the same file or other skaffold.yaml files in the current project.

  5. Test your configuration dependencies by building each of the Skaffold modules separately to make sure that they're deployed with their dependencies by following the steps in Build specific Skaffold modules and their dependencies.

Build specific Skaffold modules and their dependencies

After you've defined your modules and their dependencies, you can specify which modules you want to run with cloud code in your launch.json file.

If your project doesn't have a launch.json file defined, when you run Cloud Code: Run on Kubernetes or Cloud Code: Debug on Kubernetes, you're prompted to select the modules to build:

  1. Open the Command Palette (Ctrl/Cmd+Shift+P) and then run Cloud Code: Run on Kubernetes.
  2. Click Select modules.
  3. Choose the modules that you want to deploy and then click OK. Each module is built with its dependencies.
  4. When prompted, choose an image registry and then press Enter.

If your project has a launch.json, follow these steps to choose the Skaffold modules to build:

  1. Open your project's launch.json file.

  2. Edit the launch configuration to add the skaffoldFlags option with a comma-delimited list of modules to build. If skaffoldFlags is omitted, all modules are built.

      {
    "name": "Run on Kubernetes",
    "type": "cloudcode.kubernetes",
    "request": "launch",
    "skaffoldConfig": "${workspaceFolder}/skaffold.yaml",
    "skaffoldFlags": {
       "modules": ["MODULE_NAME_2,MODULE_NAME_2"],
    "watch": true,
    "cleanUp": true,
    }
  }

  3. Run the launch configuration you edited.

Continuous development on Kubernetes

Once you have configured your run target with the options you want, you can either opt for a regular run of your application or start a development iteration cycle on your IDE to propagate any changes made to your source and dependencies to your live application.

The Run on Kubernetes run target starts the development cycle on your Kubernetes cluster. After you start the development cycle, Cloud Code, using Skaffold, builds an image for the project, and then tags it, pushes it to the configured repository, and uses kubectl to deploy the project Kubernetes manifests.

  1. Customize your deployment using the available configuration options.
  2. If your application is configured to use Skaffold modules, you can select specific modules to build or deploy.
  3. Open the Command Palette (press Ctrl/Cmd+Shift+P) and then run the Cloud Code: Run on Kubernetes command.
  4. Confirm whether to use the current Kubernetes context to run the app in (or switch to a preferred one). For more information about setting up a Kubernetes context, see setting up configuration.

  5. If you chose a remote cluster as the context, when prompted, choose an image registry to push the images to. If your project has Artifact Registry API enabled and at least one Artifact Registry repository, you can browse to and select an existing Artifact Registry repository.

    Cloud Code builds your containers, pushes them to the registry, applies Kubernetes configurations to the cluster, and waits for the rollout.

What's next