Trunk-based development for #terraform infra makes a lot more sense, my observations after moving from a branch based model, being. Half applied/stale infra changes will not be the case anymore as compared to when multiple branches being are in active development (1/n)
As for when trying to avoid conflicts for locking states and avoiding multiple people trying to modify the same state, putting #terraform plans and applies on CI would immediately take away the need of a tool like #atlantis. (2/n)
Maintaining #terraform modules for repeated infra objects can be used as plug and play should ideally be versioned, and specific versions be used by teams. Having all of this on CI takes away the burden from ops folks of manually applying it, which reduces margin of error(3/3)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
One thing which I tried doing differently this time with one of my side projects is to do TDD from the start. Someone may ask why? It's just a side project no? (1/n)
One reason is that, for some of my past side projects, when someone creates an issue/submits a PR. I wouldn't necessarily remember everything which I did/why I did x instead of y, when I would have authored it (more on how this can be improved later) (2/n)
Coming back to say reviewing a bugfix/feature PR. Having no coverage for those specific routines which were modified, would mean I either would have to rely on my gut feeling, or I would have to test it by pulling the changes. (3/n)
Releasing v0.2.0 for Bhola github.com/tasdikrahman/b…! This release comes with the ability to push SSL cert expiry notifications to @SlackHQ for the domains which bhola is tracking
It will alert for all the domains, which have already expired/are about to expire within the buffer period which you have set & send notification to your slack channel via webhook endpoint, periodically checking in the interval set by the operator, for expiration. (2/n)
This makes bhola, tackle the part of the problem for you where you don't have to keep checking the dashboard of bhola on which certs are expiring, rather it telling you proactively, on what are the certificates which need renewal and need your immediate attention. (3/n)
Another player in the container registry space, but none the less, I now don't have to play around with my @Docker hub credentials, to push the container image for my repo's, one less thing to worry about (2/n)
Also given the recent policy change with regards to bumping off the container images if not pulled for x duration was something which I didn't wanna get put into, although completely makes sense for the maintainers of the registry. I couldn't find anything specific for GHRC (3/n)
Have been using @github pipelines for one of my public repositories and it has been a great experience so far, having the CI experience (build, lint, run tests etc.) right in front of you, was something had been missing in their UX. (1/n)
Rather than delegating the CI experience to an external entity, which would create another lookup and another thing to worry about. This pretty much has taken the developer experience a step further. (2/n)
Another killer feature, was github packages! Which means, now we have a container registry too in @github (along with a few other formats of packages supported)! Which is again building on top of github pipelines feature set. (3/n)
Do you sometimes wake up, with a call by someone from your team, telling you some SSL cert has expired? Do you keep track of SSL cert expirations on your to do notes or excel sheets? Would you like to be on top of such x509 cert renewals? github.com/tasdikrahman/b… is for you (1/n)
v0.1 of Bhola, will give you a dead simple API, which you can use to ask Bhola, to track domains which have certs attached to it. It automatically checks for the cert expiration in the background keeping note of when is it expiring. (2/n)
The operator can set a buffer period, which would bhola, then use to see if it meets the threshold number of days, before the cert is going to expire, before marking the cert, that it needs renewal asap. (3/n)
Load average seems decent so far, although the ssh is unusually laggy, no process seems to hog too much of resource, will dig on this later.
In before I brick my router on a Friday night, as I update it's DHCP config to start pushing my @Raspberry_Pi 's IP as the dns server (running pi-hole), to all it's clients.