It’s truly top-notch. It makes elegant use of all the best design patterns. It always adheres to naming conventions. It’s perfectly indented.
TL;DR: When a Cloud Build invocation is triggered by a GitHub Pull Request, you can now use the substitution values
_PR_NUMBER in the build config.
Google’s Cloud Build is a cloud-native CI/CD service available in Google Cloud Platform. When you connect it to GitHub repo hosting, you have a cloud-hosted development platform that someone else manages for you, and which is inexpensive (often, free). …
TL;DR Save in-memory data to the
/workspace volume mount, and it will be available to all subsequent build steps.
Google Cloud Build runs your build as a series of steps which execute in isolated containerized environments. After each step, the container is discarded. Poof! This lets you have totally different tools and environments for each step, and any cruft created in one step can’t contaminate the next step.
But sometimes that cruft is actually important data… you may need to persist state from one step of a build to use in subsequent steps. A common pattern would be to stash…
Because we totally need another one
DevOps is a theory:
Through continuous investment in automation and communication, we achieve measurable improvements to process velocity and systems quality.
These improvements generate value to our customers.
Like evolution, or gravity, the theory of DevOps is supported by evidence, so it grows and adapts over time. Its origin is in the technical domain (in particular, software development, deployment, and operations), but we may discover interesting things by applying DevOps elsewhere.
TL;DR: use global environment variables to specify the GKE cluster you want to work with.
Google Cloud Build is a hosted CI/CD solution that can be used to achieve low-cost, zero-maintenance continuous delivery to Google Kubernetes Engine (GKE). It’s easy to configure Cloud Build to build a container (or three), and deploy it to GKE. Deploying, of course, requires authenticating to the GKE cluster. In this post, we’ll learn an easy way to auth.
(We’ll skip right past the really hard way: manually creating a client config. …
At NYC CoffeeOps this morning, we stumbled onto an interesting idea: Virtual Machines programmed to get “rusty”—as they age, their reliability starts to degrade until they become unusable.
Yep! Here’s the context: in the cloud, we launch a lot of VM instances (and/or containers). Hopefully, at the time an instance is launched, it has no known security vulnerabilities. Hopefully! But from the moment it spins up, the risk starts creeping up: the older an instance is, the more known vulnerabilities it’s likely to have. This is why we patch systems frequently. Or, better: we frequently redeploy, overwriting old instances.
A great thing about the cloud is that it’s super easy to spin up new virtual machines (VMs). A less-great thing is that it’s also super easy to forget about all those machines you spun up, and find yourself paying for things you don’t really need. In this post, I’ll show how to use Google Compute Engine (GCE) to make VMs (also called “instances” in GCE) that delete themselves after a specified period of time, so you can fire them up, and forget about them.
This technique makes use of GCE’s Startup Script feature: when creating an instance, we provide…
“Oh, fiddlesticks! There’s a problem in prod! I need to fix it right away!
Good news: I know where the bug is. So I’ll just make this teensy little fix.
No time to run tests… it’s such a small change, I’ll just push it to prod.
And: 3, 2, 1…
…it seemed like such an inconsequential change, but it actually made things worse. I’ll admit it: I’ve done this many times. I panicked, and using poor judgment, I convinced myself I could force-push. This is how I’ve managed to turn UI bugs into crashloops, and crashloops into data-corruption…
bash as your entrypoint and add
|| echo 'failed' to your command
Google’s Cloud Build (GCB) automation system is serverless and stateless — when the build fails, the process exits and all resources used are cleaned up. That’s great for cost management and preventing security holes, but sometimes you need to keep some state around, in order to figure out what happened. In this post, you’ll learn how to tell GCB to keep going after a step failure.
For our example, we’ll use the Maven build system, along with the popular Maven testing plugin, Surefire. When
Say the magic words, and GCB opens up with hidden potential
UPDATE: There’s now a documentation page on cloud.google.com with a more thorough and otherwise better explanation of how to do bash scripting in Cloud Build. Read that, instead of this!
Google’s Cloud Build automation platform is modeled on a series of containerized “builder” steps, specified in a YAML config file. For each step, GCB spins up a Docker container, and runs a specific command within the context of that container, like
wget. You can pass one or more arguments to that command using the
DevOps Advocate at Google. My home is in Jersey City. My office is in New York. My opinions are all over the map, and may not reflect those of my employer.