<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Deployment &amp; CI/CD on 🏠</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/</link><description>Recent content in Deployment &amp; CI/CD on 🏠</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/index.xml" rel="self" type="application/rss+xml"/><item><title>19. CI/CD (CodeCommit, CodeBuild, CodeDeploy, CodePipeline)</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cicd-codecommit-codebuild-codedeploy-codepipeline/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cicd-codecommit-codebuild-codedeploy-codepipeline/</guid><description>&lt;h2 id="cicd-codecommit-codebuild-codedeploy-codepipeline"&gt;CI/CD (CodeCommit, CodeBuild, CodeDeploy, CodePipeline)&lt;a class="anchor" href="#cicd-codecommit-codebuild-codedeploy-codepipeline"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Manual deployments are slow, inconsistent, and error-prone. When every release requires a developer to SSH into a server, run scripts by hand, or remember the exact sequence of steps, mistakes happen — and scaling that process across teams and environments becomes untenable. AWS provides a suite of managed services — &lt;strong&gt;CodeCommit&lt;/strong&gt;, &lt;strong&gt;CodeBuild&lt;/strong&gt;, &lt;strong&gt;CodeDeploy&lt;/strong&gt;, and &lt;strong&gt;CodePipeline&lt;/strong&gt; — that together let you automate the entire path from a code commit to a production deployment. This is the foundation of a modern CI/CD (Continuous Integration / Continuous Delivery) pipeline on AWS.&lt;/p&gt;</description></item><item><title>20. SAM (Serverless Application Model)</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/sam/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/sam/</guid><description>&lt;h2 id="sam-serverless-application-model"&gt;SAM (Serverless Application Model)&lt;a class="anchor" href="#sam-serverless-application-model"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Building serverless applications by hand means writing long, verbose CloudFormation templates just to define a Lambda function with an API Gateway trigger and a DynamoDB table. AWS SAM (Serverless Application Model) solves this by providing a shorthand syntax on top of CloudFormation, specifically designed for serverless resources. A few lines of SAM YAML expand into the dozens of CloudFormation lines you&amp;rsquo;d otherwise have to maintain. Beyond templating, SAM also ships a CLI that lets you build, test locally, and deploy serverless applications — making the entire development loop faster and safer.&lt;/p&gt;</description></item><item><title>21. CloudFormation</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cloudformation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cloudformation/</guid><description>&lt;h2 id="cloudformation"&gt;CloudFormation&lt;a class="anchor" href="#cloudformation"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;AWS CloudFormation lets you define your entire AWS infrastructure as code — VPCs, databases, Lambda functions, IAM roles, and more — in a single declarative template. Instead of clicking through the console or running ad-hoc CLI commands, you describe &lt;em&gt;what&lt;/em&gt; you want, and CloudFormation figures out &lt;em&gt;how&lt;/em&gt; to create it, in the right order, handling dependencies automatically.&lt;/p&gt;
&lt;p&gt;The core problem it solves is repeatability. Without IaC, recreating a production environment in a new region, or letting a teammate spin up an identical dev stack, is error-prone and slow. With CloudFormation, you version-control your infrastructure alongside your application code and deploy it consistently every time.&lt;/p&gt;</description></item><item><title>22. CDK</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cdk/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/cdk/</guid><description>&lt;h2 id="cdk-cloud-development-kit"&gt;CDK (Cloud Development Kit)&lt;a class="anchor" href="#cdk-cloud-development-kit"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The AWS Cloud Development Kit (CDK) is an open-source framework that lets you define cloud infrastructure using familiar programming languages — TypeScript, Python, Java, C#, and Go — instead of writing raw YAML or JSON templates. It solves a real pain point: CloudFormation templates are verbose, hard to reuse, and lack the abstraction tools developers rely on (loops, conditionals, functions, classes). CDK brings those tools back. Under the hood, CDK still generates and deploys CloudFormation — it&amp;rsquo;s a higher-level abstraction on top of it, not a replacement. &lt;a href="https://docs.aws.amazon.com/cdk/v2/guide/home.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>23. Elastic Beanstalk</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/elastic-beanstalk/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/elastic-beanstalk/</guid><description>&lt;h2 id="elastic-beanstalk"&gt;Elastic Beanstalk&lt;a class="anchor" href="#elastic-beanstalk"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Deploying a web application on AWS from scratch means provisioning EC2 instances, configuring load balancers, setting up Auto Scaling groups, managing security groups, and wiring everything together — before writing a single line of application logic. Elastic Beanstalk &lt;a href="https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html"&gt;🔗&lt;/a&gt; solves this by handling all that infrastructure automatically. You upload your code, choose a platform, and Beanstalk provisions and manages the underlying resources. You retain full access to those resources if you need to customize them, but the heavy lifting is done for you.&lt;/p&gt;</description></item><item><title>24. AppConfig</title><link>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/appconfig/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/7-deployment-cicd-codepipeline-sam-cloudformation-beanstalk/appconfig/</guid><description>&lt;h2 id="appconfig"&gt;AppConfig&lt;a class="anchor" href="#appconfig"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Deploying a new version of your application every time you want to change a configuration value — a feature flag, a timeout, a rate limit — is slow, risky, and wasteful. AWS AppConfig &lt;a href="https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html"&gt;🔗&lt;/a&gt; solves this by letting you deploy configuration changes independently of code, with built-in validation, gradual rollout, and automatic rollback. It&amp;rsquo;s especially useful for &lt;strong&gt;feature flags&lt;/strong&gt;: you can enable a new feature for 10% of users, watch your error metrics, and expand (or roll back) without touching a deployment pipeline.&lt;/p&gt;</description></item></channel></rss>