Feature Development Plan
The plan to improve the build and dev tool stack is broken into two main categories, Dev Tool Improvements and Jenkins CI Improvements.
The Dev Tool improvements include transitioning to using Skaffold + Kustomize in favor of helm-maven-plugin,
and the Jenkins CI improvements involve fully completing the implementation of the
Jenkins Shared Library and transitioning
projects to use it instead of generating Jenkinsfiles from templates.
Dev Tool Stack Development Phase 1 (current)
Following is a high-level view of the first phase to develop the proof-of-concept Kustomize + Skaffold project, and to document a more specific strategy for migrating the rest of the services:
In support of the work to Kustomize Projects, the Convert Helm-based Kubernetes Development to Kustomize guide is useful.
Kustomize Projects
To migrate from Helm-based chart templates to Kustomize overlays, projects that are at the "bottom" of the service dependency
stack should be transitioned first so that projects that depend on them are able to reference them without relying on
specifying helmCharts in the kustomization.yaml.
This work has been started with mocks and test database instances and will continue with the "adapter" services that provide REST-ful APIs to backend data sources and web services.
The static generation of Kubernetes files like deployment.yaml, service.yaml, and horizontalpodautoscaler.yaml will
be disabled in favor of the new Kustomize-based rendering of the kubernetes/overlays/dynamic overlay to one file
(default all-kustomized.yaml) which replicates all the current Kubernetes resource configurations.
Skaffold Proof-of-Concept
After all runtime dependencies of mobile-rxrefill-service has been supplemented with Kustomize configurations,
mobile-rxrefill-service will be refactored to use Skaffold, Kustomize, and Jib for local and Jenkins build, test deployment,
and verification. This includes Jenkins CI support and building in all necessary code quality and coverage capabilities.
ci-file-generator 5.0 will be finalized with all necessary supporting features and CLI goals, including Jenkinsfile
generation and project initialization functionalities.
Once all of these aspects are operational, documentation will be created to define configuration and development conventions to guide future development of services transitioning to the new model.
Dev Tool Stack Development Phase 2
This plan will need to be updated with feedback from development of a Go-based project as well as other Java-based projects, as these projects are migrated.
There will be more focus on CI/CD improvements, possibly incorporating Skaffold into the main deployment pipeline.
Skaffold
Migrate other projects to define and use skaffold.yaml, iteratively updating the guide and supporting templates/examples
where needed.
A method will be defined to set up remote Java (and Go) debugging from within the IDE. This may involve updating the base image to allow Skaffold itself to automatically add support or adding instructions to manually configure it.
When the Skaffold + Kustomize standard configurations for dependency specification have been finalized (i.e., whether
Kustomize resources or Skaffold requires.configs should be used to include dependent services), the Dependency
Resolver Script and the corresponding service-dependencies.yaml syntax should be defined.
Once Skaffold has proven that it can handle the same tasks that helm-maven-plugin does, helm-maven-plugin will then
be officially deprecated.
CI/CD Kubernetes Improvements
This relates to the "static" Kubernetes configs that are used to deploy services to the environment clusters (not the
temporary Jenkins deployments used for integration testing). They are currently managed completely separately from the
test configs, rendering to files managed in the /kubernetes top-level directory instead of rendering on the fly using
the kubectl apply/create -k … command.
Deployment scripts should be updated to utilize the Kustomize-native option (-k) instead of deploying the pre-rendered
versions.
Jenkins CI Improvements
This can be a parallel effort to switch from ci-file-generator Jenkinsfile template-based generation to the more flexible
and maintainable Jenkins Shared Library implementation
Once each project type has been completed, projects can begin to transition to using the shared library by default.
Shared Library Development
Continue to update the Jenkins Shared
Library to add support for various project types and parameters provided in jenkins.yaml.