Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloud.google.com/code/docs/intellij/speed-up-k8s-development below:

Speed up development in Cloud Code for IntelliJ

Stay organized with collections Save and categorize content based on your preferences.

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

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.

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.

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.

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:

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.

After you've defined your modules and their dependencies, you can specify which modules you want to run in the

tab when you select

>

.

1. Install the latest Insiders builds.

2. Go to Run > Edit configurations and open the Build / Deploy tab.

3. For Skaffold configuration, select skaffold.yaml.

   Choose one of the following:

   • Build and deploy with all modules and dependencies
   • Build and deploy with (if modules are available) and select the modules you want to build and deploy.

Your selection persists for subsequent deployments. If you select a subset of modules, Cloud Code displays a warning about deploying a subset of modules and not the whole system.

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 Develop 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. Click the Develop on Kubernetes icon and then click Edit Configurations to open the Run/Debug Configurations dialog.
2. Customize your deployment using the available configuration options.
3. If you want Cloud Code to redeploy your application automatically after your changes are saved, under Watch mode - rebuild and redeploy, select On file save. New Kubernetes applications have On demand selected by default. For more information about watch modes, see Watch modes.
4. If your application is configured to use Skaffold modules, you can select to only build or deploy specific modules.
5. After you're satisfied with your configuration, click OK and then click the Run icon.

• Use Cloud Code's built in minikube cluster for local development.
• Debug your application in Cloud Code
• Read the details on Skaffold's file sync feature

To submit feedback or report an issue in your IntelliJ IDE, go to

>

>

>

to report an issue on

.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Skaffold enhances local development with file syncing for static files and hot reloading for source code, allowing changes to be reflected in seconds without rebuilding or restarting pods."],["Automatic file syncing and hot reloading are enabled by default with Buildpacks, while other builders like Docker require a `sync` section in the `skaffold.yaml` file for configuration."],["Changes to the application are deployed to the Kubernetes cluster without manual intervention when the development cycle is running."],["Skaffold modules allow for independent development and debugging of microservice sections by splitting an application into different modules, defining configuration dependencies, and selecting specific modules to build and deploy."],["The \"Develop on Kubernetes\" run target starts the development cycle, allowing for automatic redeployment on file save and enabling the use of Skaffold modules to fine-tune the development process."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4