This is another Go Continuous Delivery plugin to your build pipeline toolbelt. It’s name is quite descriptive so let’s discuss first it’s motivation. As you may know you can use Go not only for building your applications, but also for automatic deployments. Nevertheless you shouldn’t stop there yet. The Go build pipelines are ideal to orchestrate fully featured automated test workflows. So it’s not uncommon that after the deployment stages you will most likely configure your acceptance tests using for instance tool’s like Selenium or Protractor or similar. That will work on real setup with real data in addition to any unit or integration tests that you may had run durring the application build. The acceptance tests can be then immediately fallowed by stress tests or performence benchmarks using for example Gatling.
At my current project we had reach the stage when both the build and deployment was fully automatic, but any other pipeline stages require user interaction and manual triggering, mostly because there is delay between the point in time that the application was started and it becomes fully operational. Mostly because in mean time it may perform a lot of hard work: like establishing the database connections and migrating the database schema for instance. Registration in the discovery service and propagation of the registry among clients is also not instant. Due to all of this factors we had been running our tests after manually checking that the application has completed initalization and is ready to process requests.
But that is now history.
We had leverage the application health information in order to be able to tell whether it is in state that it can process the requests and we had added health checks to our build stages to automate monitoring them. Despite that this could be easly “implemnted” for instance in deployment script, this idea seemed like it had a large reusability potential. So is has been implemented as a Go plugin.
You can configure the health check task in any of your build stages. The task will delay the pipeline to the configured amount of seconds, in them same time polling your application health endpoint untill your application starts to report that is in “UP” state. If that does not happen a timeout will occur and the build will fail.
You will still need to adjust your application behaviour and define additional smart health checks, that will for instance await that your Zulu proxy (if you are using Spring Cloud and Zulu in particular) will be able to route your requests, but this can be done easly.
The implementation is reactive and uses RxJava/RxNetty under the hood, though intially it has been implemented in Project Reactor, it turn out that it may not work so well in Apache Felix the – OSGi container that is used by the Go internally.