Continuous Integration (CI) workflows are considered a best practice these days. As in, you work with your version control system (Git), and as you do, CI is doing work for you like running tests, sending notifications, and deploying code. That last part is called Continuous Deployment (CD). But shipping code to a production server often requires paid services. With GitHub Actions, Continuous Deployment is free for everyone. Let’s explore how to set that up.
Every day, we do about 12 scheduled deploys. During each deploy, an engineer is designated as the deploy commander in charge of rolling out the new build to production. This is a multistep process that ensures builds are rolled out slowly so that we can detect errors before they affect everyone. These builds can be rolled back if there is a spike in errors and easily hotfixed if we detect a problem after release.
Deploys at Slack https://slack.engineering/deploys-at-slack-cd0d28c61701
This is an interesting look at how development is done at Slack. Weirdly, I’m pretty sure I couldn’t get away with this sort of iteration anymore because our community it’s relatively small and hesitant to change.
Once upon a time I did make changes on the fly to add new features or tweak the interface but now folks depends on us to maintain a certain level of stability as they learn about it teach the law. Of course it could be that as I get older I’m less tolerant of getting pinged about changes
Small Scale Scrum can be best described as “a people-first framework defined by and for small teams (a maximum of three people) and supporting planning, developing, and delivering production-quality software solutions.” The proposed framework centers around the concept of team members occupying multiple roles on any project.
Introduction to Small Scale Scrum | Opensource.com https://opensource.com/downloads/small-scale-scrum
New – Change Sets for AWS CloudFormation | AWS Blog https://aws.amazon.com/blogs/aws/new-change-sets-for-aws-cloudformation/