Making local changes and seeing them on the target system

So far, we've seen how to speed up developer time by using automatic restarts, and we have gathered information on what Spring Boot is up to, courtesy of its autoconfiguration report.

The next step for developers is often using the debugger of their IDE. We won't go into profuse detail about that because it's highly specific to which IDE you use. However, something of extended value offered by Spring Boot is the opportunity to remotely connect to an application and make changes.

Imagine we have built up our application and pushed it to the cloud. We test a key feature in this environment because it's the only way to tie it to a particular resource or in a certain configuration. Well, the process for making changes is much more expensive. We would have to bundle things up, redeploy, restart, and re-navigate. All for a few lines of code!

Spring Boot's DevTools provide the means to connect our IDE to our remotely running application and push code changes over the wire, allowing us to automatically make mods and test them immediately.

To get geared up, we must execute the following steps:

  1. Add spring.devtools.remote.secret=learning-spring-boot to application.properties.
  2. Build the application using ./gradlew build.
  3. Push the application to the cloud (Pivotal Web Services in this case with cf push learning-spring-boot -p build/libs/learning-spring-boot-0.0.1-SNAPSHOT.jar).
  1. Instead of running the app locally in our IDE, run Spring Boot's RemoteSpringApplication class instead.
  2. Add https://learning-spring-boot.cfapps.io (or whatever the app's remote URL is) as a program argument.
  3. Launch the RemoteSpringApplication configured runner.

The following screenshot shows how to configure it in IntelliJ IDEA:

After it launches, the console in our IDE shows a remote banner:

Now, we are free to make changes in our IDE, Save/Make Project, and watch them propagate to our cloud-based app running at https://learning-spring-boot.cfapps.io.

First of all, let's tweak our template at src/main/resources/templates/index.html. We can add a sub-header below the main header similar to what we did earlier in this chapter:

    <h1>Learning Spring Boot - 2nd Edition</h1> 
 
    <h2>It's really handy to make local edits and watch them go out
to the cloud automatically</h2> <h4 th:text="${extra}"></h4>

Hitting Save or Make Project, the code change will be uploaded to the cloud and trigger a restart (this is a great opportunity to use the LiveReload server and automatically refresh the page):

With this flow, we can make all sorts of changes. When ready, we can commit them locally, build a newer JAR file, push to the cloud, and continue forward.

It's always recommended to use https:// when connecting to a remote application. It prevents other users from snooping the network for secrets.
Enabling Spring Boot DevTools on a remote application is a risk. The only thing protecting the application from code updates is the simple secret the two share. You should never enable this on a production deployment.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.135.213.212