This document discusses the benefits of continuous integration using Jenkins. It explains that continuous integration helps eliminate bugs by running automated tests frequently to catch errors early. This allows teams to work more efficiently by preventing the need to revisit features after integration. Jenkins is highlighted as a tool that can run tests automatically, notify teams of failures, and help set up new machines for continuous integration workflows. Setting up scripts in source control is recommended so the Jenkins process can be repeated reliably.
18. Palomino Labs, Inc. palominolabs.com
Drew Stephens
drew@palominolabs.com
@dinomite
Notas del editor
Principal at Palomino Labs; software development consultancy Desktop webapps, native mobile apps, low level systems programming, and big data Also process consulting, focusing on making teams more efficient
GORUCK challenge is about building an efficient team
If you don’t understand why you’re doing something, you’re going to have a bad time
The core of what we’re trying to do with CI & lean principles is efficiency
We’re trying to eliminate waste and the prime way to do that is reducing bugs Finding & fixing bug is a waste of time; the best thing to do is eliminate them Writing testable code and the tests for it, be they unit or more comprehensive, helps prevent bugs in the first place Tests find regressions early
Be it bugs or simultaneous feature development, context switching is costly. By eliminating bugs you decrease the need to revisit features.
Be it bugs or simultaneous feature development, context switching is costly. By eliminating bugs you decrease the need to revisit features.
Be it bugs or simultaneous feature development, context switching is costly. By eliminating bugs you decrease the need to revisit features.
Must have automatic test runs Stop the line reduces cost of context switching—find problems sooner
Jenkins has this box. Many are tempted to do things in it. They cry when the something goes wrong and they lose their build script. Relate to database triggers—hidden code that is ungreppable
Even though DB setup ought to only happen once, you’ll be happier (and prevent potential failures) if you check it every time.
Interaction between sdms-cucumber & s3cp Mocks are OK for unit tests, but not integration—systems can change without the mocks being updated Selenium tests take a while—use Sauce or VMs
HIPAA requires proof of tests run against code on production We’re keeping data in OpenTSDB, producing graphs for each Jenkins run