1. Cncf-Helm
  2. Topics

How are people estimating efforts for developing and maintaining Helm chart based product releases?

Sandip Chitale
 

This is a somewhat open ended question but I am looking for some real world, practical knowledge/experience about effort estimation for developing and maintaining Helm chart based products.

Helm3 is supposed to make deployment of applications to Kubernetes platform easy. The helm install/upgrade/rollback single commands to do the deployments on the surface make it sound easy. But this is slightly deceptive though. The actual process involves:

  • Development of
    • Docker files
    • Helm Charts
      • Fresh install use case
      • Upgrade use case
      • Evolution of values files from release to release
  • Automation of builds on CI
    • Build Docker images
    • Build Helm packages
  • Automation of testing with built Docker images using the helm chart
    • testing fresh installs
    • testing upgrade
      • implement backup before upgrade strategy
    • testing rollbacks
      • implement restore after rollback
  • Implementation of tag and helm chart versioning pre-test and for release
  • Build and prepare release artifacts for Docker images and Helm package
  • Supporting fresh installs
    • Documentation of the values files and process
  • Supporting upgrades
    • Documentation of the values files evolution for customers previous version of values files and process of backup, upgrade
    • Dealing with upgrade failures implement recovery using backup/restore and helm rollbacks

I am looking for information like what effort estimation/story points estimation  strategies people are using. 

Practically, how many people are working in your teams on the full development lifecycle discussed above. Of course this may vary from team to team and product to product. All aspects above may or may not apply to your projects.

I think how to estimate java, dotnet, frontend projects is relatively well as we have been developing those for some time.

Do you have any insights to share?


Thanks.
Loritsch, Berin <bloritsch@...>
 

Helm definitely has some wrinkles, and I've run into a few.  So I would recommend separating your tasking.  For example:
  • Writing docker files and helm charts are separate activities, they deserve separate estimates
  • Design your helm chart--identify what needs to be externally configured to include it in a larger deployment?  That's a separate estimate that you might be able to apply the results across all your services (if you have a microservices environment)
  • Writing the chart itself--design for the fresh install scenario
  • Do your deployment testing
You do have to understand one thing: Helm templates kubernetes YAML files.  Helm owes its ability to upgrade in place to the underlying kubernetes infrastructure.  Kubernetes YAML files are declarative, not procedural.  In other words you declare what you need, not how to make it happen.  The helm command line will make sure the right calls are invoked to get your desired infrastructure, but it's Kubernetes doing the heavy lifting.  In theory fresh installs and upgrades don't look any different to a Kubernetes cluster.

You do need to test those scenarios, but they shouldn't be separate tasking.

Regarding CI/CD, I recommend you look into the various Continuous Deployment tools for Kubernetes clusters.  For example, FluxCD and/or ArgoCD both work with Helm and manage your configuration and deployment for your environment(s).  Your Continuous Integration platform of choice builds the different packages (containers and helm charts) and deploys them to your local repository (like Sonatype Nexus or JFrog Artifactory).  Your CD tool of choice pulls those new packages from that repository and updates your deployments as necessary.

It's a lot of moving parts, but each part does have a specific purpose.

On Wed, May 5, 2021 at 10:41 PM Sandip Chitale <sandipchitale@...> wrote:

This is a somewhat open ended question but I am looking for some real world, practical knowledge/experience about effort estimation for developing and maintaining Helm chart based products.

Helm3 is supposed to make deployment of applications to Kubernetes platform easy. The helm install/upgrade/rollback single commands to do the deployments on the surface make it sound easy. But this is slightly deceptive though. The actual process involves:

  • Development of
    • Docker files
    • Helm Charts
      • Fresh install use case
      • Upgrade use case
      • Evolution of values files from release to release
  • Automation of builds on CI
    • Build Docker images
    • Build Helm packages
  • Automation of testing with built Docker images using the helm chart
    • testing fresh installs
    • testing upgrade
      • implement backup before upgrade strategy
    • testing rollbacks
      • implement restore after rollback
  • Implementation of tag and helm chart versioning pre-test and for release
  • Build and prepare release artifacts for Docker images and Helm package
  • Supporting fresh installs
    • Documentation of the values files and process
  • Supporting upgrades
    • Documentation of the values files evolution for customers previous version of values files and process of backup, upgrade
    • Dealing with upgrade failures implement recovery using backup/restore and helm rollbacks

I am looking for information like what effort estimation/story points estimation  strategies people are using. 

Practically, how many people are working in your teams on the full development lifecycle discussed above. Of course this may vary from team to team and product to product. All aspects above may or may not apply to your projects.

I think how to estimate java, dotnet, frontend projects is relatively well as we have been developing those for some time.

Do you have any insights to share?


Thanks.



--
Berin Loritsch

DOMEX Architect


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708
Sandip Chitale
 

Hi Berin,

Thanks for your comprehensive response.

Best Reagrds,
Sandip

1 - 3 of 3