In the old days (and not so old days), creating and maintaining a website or developing an app was such a tedious process. Most developers would create/update a website/application on their local PC and then via FTP (hello, utterly insecure) upload their changes to a single server. Many small IT shops would offer this service by hosting a server in their basement at home. The better ones would host on colocated servers. I’m surprised how many small firms are still hosting websites on these single points of failure. Changes were so slow and time-consuming that many just stopped updating their online presence or applications. 

We all know about approval processes and peer reviews. In some organizations, this could take weeks or months. Some developers would ride out the approval process of changes like this: 

Manager: Sees John running around out of breath and asks, “John, what are you working on?” 

John: “I’m waiting for approval on the changes I made to the website.” 

Manager: Realizing he’s the holdup, but refusing to let John know that he knows, “Let me escalate that for you.” 

John: Sits back doing nothing for the next few weeks. 

How the hardworking lazy do it 

Mary is very lazy and hates repetitive tasks and truly dislikes approval processes. She invests a lot of time setting up her development environment so that she doesn’t have to deal with mind-numbing repetitive tasks. Now with a simple command or click of a button, her website updates have this workflow: 

1. Mary sends updates to a GIT repository 
2. GIT pipeline notices these updates 
3. GIT pipeline sends updates to an S3 bucket in AWS (in seconds) 
4. AWS Cloudfront checks the S3 bucket for updates (in seconds) 
5. AWS Cloudfront distribution sends those updates throughout the world to edge locations closest to your users (not someone’s basement). 
6. Rinse and repeat multiple times a day 

This process is part of a practice called Continuous Integration and Continuous Delivery or simply CI/CD. In the simplest of terms, it is hardworking laziness 101. In the conversation between John and his manager, John made one measly change and did nothing for weeks while Mary made dozens of changes in one week. In fact, Mary, the lazy one, will make more updates in a few weeks than John will make in his whole time at the firm. 

In this example, we used a feature in BitBucket called Pipelines, which integrates nicely with AWS. Other repositories provide a similar process. By inserting the following YAML file in the directory, you will have a functioning CI/CD implementation. 

bitbucket-pipelines.yml 

image: yourpreferredlinuximage/aws

pipelines: 

default:

– step: 

script: 

– aws s3 sync –delete . s3://www.yourwebsite.com 

AWS Cloudfront CDN 

The above script references an S3 bucket with the name of your website s3://​www.yourwebsite.com​. Then your Cloudfront distribution monitors this S3 bucket and propagates changes as they are received. Like most things in AWS, there are so many configuration options, and as always AWS does a great job with the documentation. Many organizations will run there web app on load balanced VMs and use Cloudfront to distribute images, videos, and files. This way, the CDN does the heavy lifting.