Serverless CI/CD demoed on AWS

A software build usually runs on a machine that waits around all day for work. The new demo showed the opposite setup: code pushed to GitHub started short-lived jobs on Amazon Web Services, then those jobs disappeared when the build and tests finished. (docs.github.com) (aws.amazon.com) That sounds small until you remember how most delivery pipelines are built. Many teams still keep dedicated runners, virtual machines, or container hosts alive just so a test suite can wake them up for 10 minutes a few times an hour. (docs.github.com) (aws.amazon.com) Serverless computing flips that model. Instead of renting a whole apartment for one package delivery, you pay for a few minutes in the lobby, use the space, and leave. Amazon Web Services services such as AWS Lambda and other event-driven components are built around that idea. (aws.amazon.com) Continuous integration and continuous delivery is just the assembly line for code. A developer changes a file, the pipeline compiles the project, runs tests, packages the result, and then ships it to production if every gate passes. (aws.amazon.com) GitHub Actions is one common way to trigger that assembly line. GitHub calls each automated step a workflow job, and those jobs can run after a push, a pull request, or another event in the repository. (docs.github.com) (aws.amazon.com) The tricky part is that build systems need a place to stand while they work. A compiler needs memory, tests need files, and deployment steps need credentials that let them touch cloud resources. Long-running servers solve that by existing all the time, but they also need patching, monitoring, and cleanup. (aws.amazon.com) (docs.github.com) The demoed approach used GitHub Actions as the starter pistol and Amazon Web Services as the temporary workshop. That is already a documented pattern in Amazon’s own serverless guidance, where a workflow checks out code, installs the AWS Serverless Application Model tools, builds the app, and deploys it into an Amazon Web Services account. (docs.aws.amazon.com) (aws.amazon.com) In plain terms, the pipeline borrows infrastructure instead of owning it. A job starts, downloads the repository, runs build commands, stores the output somewhere durable, and then the compute layer can vanish without losing the result. GitHub calls those saved outputs artifacts. (docs.github.com) Artifact storage is the part people forget until a later stage needs yesterday’s output. If one short-lived job compiles a package and another short-lived job deploys it, the package has to be uploaded to a durable store in between, or the second job has nothing to pick up. (docs.github.com 1) (docs.github.com 2) Credentials are the other sharp edge. A pipeline that creates or updates Amazon Web Services resources cannot safely rely on permanent cloud keys pasted into repository secrets forever, so GitHub and Amazon both document OpenID Connect, a setup where GitHub presents a signed identity token and Amazon Web Services returns temporary credentials for one role. (docs.github.com) (aws.amazon.com) That temporary-credential model fits the serverless idea almost perfectly. The job exists for a short time, the credentials exist for a short time, and the trust policy can be narrowed to one repository, one branch, or one deployment path instead of opening the whole account. (docs.github.com) (aws.amazon.com) The appeal is obvious for small teams and side projects. If there is no runner fleet to patch, no idle build server to pay for, and no machine image to babysit, the maintenance load drops to workflow files, identity rules, and storage settings. (docs.github.com) (aws.amazon.com) The catch is that “no servers to manage” does not mean “no system to design.” Someone still has to decide where artifacts live, how long they are kept, which role each workflow can assume, and what happens when a build needs tools or caches that do not exist after the job ends. (docs.github.com 1) (docs.github.com 2) (docs.github.com 3) So the lesson from the demo is not that every delivery pipeline should become serverless tomorrow. It is that build and test stages, which often run in bursts and then sit idle, are unusually good candidates for ephemeral, pay-for-use infrastructure if the team is disciplined about temporary credentials and durable artifact storage. (aws.amazon.com) (docs.github.com 1) (docs.github.com 2)