Electron
Last week, I wrote about releasing Electron applications on macOS, going into detail on the specific steps required to go from source code to packaged application. Building your app on your development machine is one thing, but ideally, you want to publish new builds as soon as a commit is
Anzu
While some projects require complex setups and resources from different cloud providers, sometimes you just want to run a container in the cloud and we hear you! Today, Anzu is introducing Managed Containers, a dead-simple way to get your container running in the cloud. The best part? For exploration purposes,
Anzu
In last week’s post, I wrote about how Anzu Services help engineering teams bridge the gap between the cloud and their codebase by leveraging code generation and the provider ecosystem to connect resources to services within seconds. This week, I’ll focus on Anzu Dev Environments: Developing software locally
Anzu
At Anzu, our mission is to help teams move faster, happier. We want to help make the work of building and shipping services fade into the background, so you can focus on building instead. One of the big pillars to achieving this mission is to reduce the effort associated with
Automation
Two weeks ago, I wrote about enforcing required status checks in GitHub actions. This was required in scenarios with sharding or running tests in parallel. Today, I wanted to extend this to setups with multiple services, which create a different dynamic: When files in a service change, you want to
Automation
A very important GitHub feature for teams is to configure branch protections. These typically include requiring pull requests and a minimum number of reviews, preventing force pushes to main branches, signing commits, and most importantly, passing status checks. Status checks can be added by external services to commits to signal
Automation
Building and pushing Docker images is one of the most common tasks in the deployment pipeline of most engineering teams. We usually want to build the images ahead of time to create a repository of images we can use for our deployments, or are required to do so in case
Automation
When you manage websites with more than a dozen pages, it can get hard to make sure search engines like Google know when to index newly-added content. Some pages may change frequently, and the classic way of publishing a page, then waiting a couple of days to see if Google
SaaS
Building software is hard. Typically, engineering teams use dozens of services for building, deploying, monitoring, and analyzing their product, as well as providers for billing, internal tooling, customer service, and so on. Once a product is deployed in production, it is continuously refined and expanded with new features, which may
Infrastructure-as-Code (IaC)
How many third-party services and resources does your application use? For a regular web application, you need a place to host your frontend, deploy your APIs, store files, a database for user accounts and other application data, maybe some queues for decoupling tasks, monitoring integrated with every service you deploy,
Automation
About five months ago, Notion launched their long-awaited public API. The team initially delivered basic features and continuously improved the surface with more functionality and block types to support a growing number of use cases. I use Notion for, drum roll, note-taking. I create a page every day to take
Systems Architecture
Testing the changes in a pull request isn't intuitive: checking out the branch, waiting for Docker to launch all service containers, keep waiting for another bit, then getting to test the actual PR. By the time you reach the last step you might have forgotten what you initially
Systems Architecture
In my recent post, I talked about how we reduced deployment times of our Infrastructure-as-Code workflow with Pulumi. The benefits of managing all resources you're deploying in a declarative way are manifold, including observability of what you're running, security in the sense of using encrypted secrets,
Systems Architecture
The faster you can release changes, the faster you can ship new features, fix bugs, and solve incidents. But there's more: The less time it takes to think about deploying to production, the more time your engineers get back to work on meaningful tasks or spend their time
Automation
When you maintain more than a couple of projects, managing dependency upgrades, code quality checks, tests, and publishing releases becomes a chore you'll inevitably face during a project's lifecycle. In addition to this being neither fun, nor a rewarding task, it consumes a lot of time
Open-Source
A few days ago, I published my introductory post on a freshly-released tool called compose-deploy, which can be used to deploy your Docker Compose application to a group of deployment targets using nothing more than ssh and built-in Docker (and Docker Compose) features. Since then, I have tried to think
Open-Source
When developing dockerized applications, you might stumble upon the sheer difficulty and annoyance of simply deploying your Compose file along with built service images. If you're not using a full cloud setup and instead want to deploy to a small number of machines, you're left with