The CI/CD and DevOps Blog

Dr Dobbs Journal has a great post in praise of small commits. As Jeff Ma points out, small commits have multiple benefits -

• Smaller commits = Less code complexity = easier to understand = easier to test and debug
• Smaller commits = faster code reviews = quicker feedback from reviewers
• Quicker feedback from reviewers = less (mental) context switching for the developer

As Jeff says -

In a continuous integration environment, the speed at which commits are tested, added to the build, and possibly reverted is paramount. Builds are also faster for small commits because they are, by nature, smaller. Faster and more frequent builds translates into getting the product out faster and getting feedback more quickly. And because the commit is small, if you need to revert back to an earlier version of a build, that is also easier to do. An added benefit is that if you need to remove a commit that has a small scope of functionality, only that piece needs to be removed from the build, which leaves other features intact.

You can check out how Shippable can help you #shipcodefaster!

Mary and Tom Poppendieck in their book Implementing Lean Software Development ask -

"How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?"

You can also ask the very same question in a different way - how many engineers does it take to deploy a single line of code change? (and how much time will it take them?)

Just a sample of the questions you need to ask before coming up with an answer to that question -

How much testing will you be required to perform?

How much supporting documentation will you be required to produce?

How long will you have to wait for a test environment?

How many dependent systems will you need to test?

How long will it take to approve the change?

And, last but not least, how many of those activities add value, and how many waste time?

As Martin Fowler tweets -

https://twitter.com/martinfowler/status/437913623118090241

Jez Humble of Thoughtworks makes the case for continuous delivery -

• Continuous delivery makes releases routine, every day (even several times a day) occurrences -  for instance, Etsy says that a new engineer deploys on their very first day(even before they finish all their new employee paperwork).
• Deploying more frequently improves the stability of web services allowing companies toship code faster, to have fewer failed deployments and even if the deployment fails, to restore service faster.
• By automating the build-deploy-test-release process, continuous delivery lets teams perform these on-demand and both reduces the cost of development AND increases number of programs under development.

For more on how Etsy and Flickr implement continuous deployment, check out theengineering blogs for Etsy and Flickr.

GitHub announces new and improved ways to configure, customize, and debug webhooks.

A webhook is basically the way a GitHub repository "talks" to a web server whenever the repository is pushed to.

As the webhook guide explains - These “webhooks” can be used to update an external issue tracker, trigger CI builds, update a backup mirror, or even deploy to your production server.

Webhooks can now be configured directly as part of the repository settings (no API needed!).  And webhooks are now easier to debug and even re-send. Webhooks are already one of the most widely adapted GitHub integrations and now that they are even simpler to use, will surely continue to be so!

Greg Jorgensen of Typical Programmer posts his take on why software methodologies don't work.

As Greg explains -

My own experience, [...], is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process.

Common vision (AKA the way we do things around here) is perhaps especially important, when your goal is to move fast and break things. And what better time to start than when on boarding a new engineer?

As Facebook's Joel Seligstein puts it -

I would describe it as a way for us to educate our engineers not only on how we code and how we do our systems, but also how to culturally think about how to attack challenges and how to meet people.

And as we briefly touched on before - a successful dev culture encompasses the entire process - all the way to deployment. For instance, in an older post, Greg talks about how to develop code which is impossible to maintain -

A key part of developing unmaintainable code (as per Greg), is to create a super elaborate build and deployment structure. As he puts it -

Programmers can argue about simplicity and elegance in code, and then turn around and build the most elaborate and baroque build and deployment systems.