Good Unit and Integration Testing Practices
Of course, the option of automating presumes that you have a robust test suite. Having a robust set of unit tests, ideally covering over 90% of the code base, allows a developer to test a change against the code base prior to committing that change to the repository. If the change causes any of the tests (often numbering in the thousands) to fail, the developer fixes the code.
In new systems, design practices such as test-driven development should be employed to ensure that new code is the result of an appropriate testthat is, a test that describes what "works" for that unit. However, this option may not be possible with legacy systems that weren't developed with testability in mind. For these kinds of systems, various other techniquesparticularly those defined in Michael Feathers' Working Effectively with Legacy Codecan be employed to pull out code into testable parts over time.
Both legacy systems and new systems benefit from integration tests in the build pipeline. Whereas unit tests test individual units, integration tests work the "seams," where pieces fit together, to ensure that various components integrate well. Integration tests are usually fewer in number because they're harder to develop and take longer to run, but they're crucial for testing things like databases, permissions, and other systems factors that tend to be a large source of production bugs.
Of course, all this testing has an initial development cost. Becoming physically fit usually has initial costs such as gym memberships and the like, but the long-term benefits of fitness are hard to deny. Similarly, the benefits of automated testing tend to accrue quickly as more tests are added.