This TravisCI blog post welcomes AJ to the team. In it, there is a bit that caught my attention (except, of course, the one about bra burning):
If you’re so inclined, you can follow her on Twitter or run curl cv.soulshake.net.
Wait a second … A what? curl for the CV? I had to try it out. Here’s an even better way, for reading all the slides:
p=1; while [ $p -lt 9 ]; do curl -N cv.soulshake.net/$((p++)); read; done
Oh. My. God. Lo and behold, this is the coolest tech CV I’ve ever seen. Ever. Period. TravisCI is so lucky to have her!
P.S.: If you are interested in how this was done, here a couple of blog posts – one and two.
Once we are happy with the TravisCI configuration, we’ll be bringing this setup to our BitBucket Pipelines environment as well.
The setup is also based around CakePHP framework, but it’s easy enough to adopt it to any other framework, PHP or not.
“S3 static site with SSL and automatic deploys using Travis” is a goldmine of all those simple technologies tied into a single knot for an impressive result. It has a bit of everything:
- Jekyll – simple, blog-aware, static sites engine, for managing content.
- GitHub – for version control of the site’s content and for triggering the deployment chain.
- Travis CI – for testing changes, building and deploying a new version.
- Amazon S3 – simple, cheap, web-enabled storage of static content.
- Amazon CloudFront – simple, cheap, geographically-distributed content delivery network (CDN).
- Amazon Route 53 – simple and cheap DNS hosting and domain management.
- Amazon IAM – identity and access management for the Amazon Web Services (AWS).
- Let’s Encrypt – free SSL/TLS certificate provider.
When put altogether, these bits allow one to have a fast (static content combined with HTTP 2 and top-level networking) and cheap (Jekyll, GitHub, Travis and Let’s Encrypt are free, with the rest of the services costing a few cents here and there) static website, with SSL and HTTP 2.
This is a classic example of how accessible and available is modern technology, if (and only if) you know what you are doing.
TravisCI – a continuous integration service – shares some of the insights from over 2,000,000 builds they’ve run, in an blog post called “What We Learned about Continuous Integration from Analyzing 2+ Million Travis Builds“. For me, the most valuable bit is about the reasons for failing builds, which clearly indicates the need for and the importance of unit, integration, and UI tests:
Around 20% of all builds fail. There is a variation based on the language – for some programming languages, testing is part of the process and culture – for others it’s an acquired tool. Once you do implement testing, most of your builds will run. You’ll cancel very few. But about 20% will fail due to failed unit tests, configurations, or environment setups. Catching these 20% before it hits production is super important.