Check in early and often

Continuous Delivery has to be lived by the whole team. Developers who work on features or bug fixes should check in into the master branch early and often. This is crucial to enable Continuous Integration. The more time passes before changes are merged into the master branch, the harder the merging and integration of features becomes. Adding complex functionality in a big bang contradicts the idea of continuous evolution of software. Functionality that should not be visible to users yet can be excluded by feature toggles.

Checking in often encourages developers to write sufficient, automated software tests from the beginning. This is certainly an effort to make during development but will always pay off in the long run. While developing a feature, engineers are aware of its functionality and boundaries. It's far less effort to include not only unit tests but sophisticated end-to-end tests from the beginning then it is after the feature has been written.

Especially for less-experienced developers it's important to mention that committing early, premature versions of features is nothing to be embarrassed about, but part of the development process. Code which hasn't been refactored yet and doesn't look perfect, but fulfills the requirements and provides business value, can be cleaned up in a second run. It's far more helpful to commit code early in the process than refraining from committing until the very last minute.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.189.171.153