https://pantsbuild.org/ logo
Join Slack
Powered by
Hi again, I'm now looking for advice on best-pract...
# general
r
Hi again, I'm now looking for advice on best-practices for integrating pants with CD (probably Argo): My initial thought is to have a staging environment that tracks main, which is continuously deployed; this seems straightforward as we can detect incremental changes (eg serviceA) and only re-deploy that service. However I'm not sure what the best way to handle prod environment deployment is. My initial thought is to tag a particular commit, but that suggests a rebuild and redeploy of everything, which feels nice and atomic; however realistically I don't think we want to redeploy everything on every release (or do we?). We're wondering about the ability to roll out hotfixes easily, without redeploying everything, and wondering if there's any well-known patterns around this with pantsbuild.
g
I don't think I can offer much practical advice since it depends so much on your service pattern etc, but we rely heavily on https://argo-rollouts.readthedocs.io/en/stable/ and do live-at-head. Development uses traffic routing/tagging and mirrored deployments, so multiple things can be happening on the same cluster without interfering with each other and the default routes just hitting the "main" services
❤️ 1
r
Thanks for the pointer! Looks like I have some reading to do
e
At my org we build helm charts via pants and our CI/CD pushes helm charts to artifactory. (We have a 
0.0.0-main-<timestamp>
pattern for latest version of main and a 
x.y.z
pattern for tagged release versions) Then our dev/testing environments set argoCD to use version 
>0.0.0-main-0000000000, <0.0.0-main-9999999999
(or something like that, my syntax might be off). And more stable environments can set argoCD to use a specific 
x.y.z
version
We avoid redeploying everything by having every module maintain a separate helm chart, (and allow that the timestamps don't have to match up), so if we only build and push (to artifactory) the helm charts that have changed, then argoCD will take care of only synchronizing those changes
r
@elegant-florist-94385 thanks for weighing in! Does each module have its own x.y.x version and they are updated independently?
e
we have an org-mandated release process, so the versions are all updated at the same time.
The 
0.0.0
version is sort of our continuous deploy process (where the timestamp is the true "version") and these are all independent per-module. the environment's argoCD will just pull the latest and so any particular module can get deployed as soon as it has changes (which lead to a new helm chart). The 
x.y.z
version is more about controlling customer release cadence (we work on utility grids, so there is a lot of concern about fully tested release candidates and very stable releases, etc.). Basically we work like continuous deployment and then make snapshots of everything at one time for the 
x.y.z-rc1
version, and then let individual modules test and bugfix with 
rc#
versions to ensure a stable release
r
Got it, then does 
x.y.z+1
entail a deploy of everything in production? Just curious if this is something we'll have to live with if we want atomic commit -> production
e
Well... define "production". Our case is an application that would be deployed for a specific customer (usually an on-premises k8s cluster). We don't deploy to "public internet with end-users" really. From my perspective "production" is "I pushed the helm chart to artifactory, its available to everyone". Though in reality, a customer would usually not have this chart immediately deployed, but would choose to upgrade when they are ready (ie. by updating the target version in argoCD). Essentially, publishing helm charts to artifactory allows each customer to define their own upgrade schedule just by setting the target version in argoCD. (specific version = manual opt-in process, narrow range = automatic minor version upgrades but opt-in major version upgrades, wide range = full CD, etc.)
r
Ah I see, so something like library publishing , that makes sense
e
Yeah, I think the main idea is that using something like artifactory as a buffer between your repo and prod enables you to push as frequently as you want, but the consumer (ie. argoCD) can still control their own update frequency
and then, to your original question on redeploying everything vs partial: There are 2 controls you have for this: • make a number of smaller apps/helm charts ◦ then argoCD will consider each one independently for versioning and synchronizing ◦ you would have to independently manage some form of "which versions of each app are compatible with each other" • pants dependency control: ◦ you may choose to only rebuild docker containers that have changed ◦ (assuming one gigantic helm chart, but the principle would still apply for multiple): rebuild the helm chart such that it refers to the latest versions of each docker image (whether they have been rebuilt or still using the older ones because no changes) ◦ when argoCD synchronizes this helm chart, it should be able to recognize that the actual diff to the environment is small and only make changes to those containers that have actually changed.
❤️ 1
r
Thank you for the advice!
e
no problem. Hopefully its helpful!
❤️ 1
16 Views
Open in Slack
PreviousNext
Powered by