1. The Goals
1.1. I want you to be productive... every day
1.2. I want you to give you options on how to stop fearing merging and how to start improving your product confidently
1.3. I want you to stop thinking of your code as a version and start thinking of your code as a living entity
2. Presenter Info
2.1. Nicholas Tuck
2.2. This preso url: buildfordisable.nicholastuck.com
2.3. TheSoftwareGardener.com
2.4. twitter: @nicholastuck
2.5. Find me on G+ (not kidding) seriously...
2.6. Preso Title: Your Code is Not a Version: How 'Build for Disable' can bring you true continuous integration
3. The Room for Improvement (room picture?)
3.1. Commit graph with feature branches (1a)
3.1.1. This might be how you integrate with your team
3.1.2. A couple features might be done in the middle
3.1.2.1. Most merging is happening at the end
3.1.2.1.1. If you use git or mercurial this week sucks
3.1.2.1.2. This is a workflow that you can make work, but it's not productive
3.1.2.1.3. Ontop of the difficulties actually developing, this means all testing done on feature branches have limited value
3.2. Commit graph with highlight of duplicate work (1c)
3.2.1. You ever write the same code or fix the same problem that someone else did?
3.2.1.1. When you did, you ever do it so differently you have to spend a lot of time convincing the other guy the way you did it was way better than his way and he should fix his code, your's is fine
3.2.2. It's not just about duplicate work, we could actually be helping eachother.
3.2.2.1. Imagine if the other guy committed some fixes to the baseline and saved you from wasting hours trying to figure out what you did wrong
3.2.3. Some of you have processes that you should pull and merge every couple days. I agree you should pull and merge daily.
3.2.3.1. The problem is there's not much to pull in most of the time because just like you aren't pushing, neither is anyone else. So it's not helping like it could be.
3.3. Commit graph with a release and all the features that didn't make it (1c)
3.3.1. Have you ever written a major feature but just didn't make the cut off?
3.3.1.1. How often is that code 100% new that didn't effect the rest of the baseline? Maybe a bug fix to an existing feature that you had to fix for the new feature to work
3.3.1.2. These constant daily improvements are not making into our releases and that's not good.
3.3.1.2.1. Show improvement line graph of choppy up lines as branches are merged at different levels of improvement (3)
3.3.1.3. Moreso these improvements are not making it to eachother as team members causing us to waste time on the same bugs, the same refactoring, or maybe just simply the same troubleshooting. Overall it's time wasted that we can improve.
4. Simple Solution
4.1. Commit hourly and push daily
4.1.1. This is not just DVC commit hourly, this is actually push to the public repo daily
4.1.2. It's really not a novel idea, it's the obvious ones
4.1.3. Commit graph with constant pushes and merges (2a)
4.1.3.1. What does it mean?
4.1.3.1.1. If you worked on a feature for a few hours, you added tests around all the work and changes, push your code out to everyone else.
4.1.3.1.2. Fixed a small bug thats a handful of lines of code. Write the test and push the code
4.1.3.1.3. Working a big feature that will take days, maybe weeks, write a couple hours worth and push it to everyone.
4.1.3.2. How is this an improvement?
4.1.3.2.1. When you push daily you merge daily.
4.1.3.2.2. Continuous testing.
4.1.3.2.3. Your application is ALWAYS improving.
4.1.3.3. To do this we have to break some developer taboos you were taught but never fully understood
4.1.3.3.1. taboos
4.1.3.3.2. rules you want to re-enforce
5. Build for Disable Techniques
5.1. Simple if check with a static boolean
5.1.1. Code example
5.2. Add a method for the alternate way and static boolean
5.2.1. Code Example
5.2.2. Writing tests could be challenging as you enable and disable.
5.2.2.1. make this boolean protected and set for the tests you will fail. Then when going to production remove all the tests with the opposite set.
5.3. Extend the class and override the methods you want to change. Point the app config at the new class, and to disable point to old class
5.3.1. Code example
5.3.2. This keeps tests separated from the other tests. Then when ready to pull in, copy the tests in. Walk the failing tests and ideally remove them all, but not if you broke something unintended.
5.4. Actually USE interfaces!!
5.4.1. Decorator Pattern
5.4.1.1. Code example
5.4.1.2. Tests and class can stay in place if desired. Sometimes this is a good design, sometimes not.
5.5. Leads to better coding practices in general
5.5.1. Sometimes you find out, this is better architectually and that functionality shouldn't be mixed in where it was.
5.5.2. Writing code in separate and distinct groups is easier to test, easier to maintain.
6. Why Isn't Everyone Doing This? Introducing 'Build for Disable'
6.1. The reason why you don't see more teams doing true continuous integration is because we believe our code exists in versions
6.1.1. Show commit graph of feature branches and every merge is versioned (1d)
6.1.2. We have hammered into our heads we are working for weeks to deliver an idealized version of our code to production
6.1.2.1. This version of code is on a pedistal of only code that was done is commited, only code that works without bugs (yah right...), all features undone are in a different version.
6.1.2.1.1. Code, with a cape, in a first place stand
6.1.2.2. We try to have the public repo represent perfect versions of the code because that makes us feel warm and fuzzy inside.
6.1.2.3. It's also because we develop processes around our tools. We model our process on how the tool represents our code, thus svn branches == feature branches
6.1.2.3.1. We need to develop our process and find a tool that works
6.1.2.4. Mostly we do this as it is our only single mitigation on how not to ship a product with half working features or buggy features.
6.1.2.4.1. Show commit graph where branch feature doesn't make it, simple mitigation, no complications. (1a - double sided tape R)
6.1.2.4.2. One) This is a myth. We have all dealt with that guy who pushed code to head when he shouldn't have and we scramble to learn all the fancy features of our version control to pretend like it never happened
6.1.2.4.3. Two) Adding more restrictions on who can push and when we can push doesn't make us more productive, it makes us slower, much slower
6.2. I have a solution
6.2.1. Your Code is NOT a Version!
6.2.1.1. Your code IS a living entity.
6.2.1.1.1. It is always improving, it is always moving forward, it's always changing.
6.2.1.1.2. It's being fed while you push code, it's being excercised under test and it's being releived during refactoring. It is basically alive.
6.2.1.2. We need to stop constantly looking back at what we feel might be stable versions and spend more time looking ahead and creating the product we want to ship
6.2.2. Introducing 'Build for Disable' (Also called Branch by Abstraction VS Branch by Source Control) (Similar to Feature Toggle)
6.2.2.1. This is not my idea, this is something many of us here do every day but we do it for different reasons. I want to generalize those reasons today.
6.2.2.2. What is it? It's a simple idea
6.2.2.2.1. Build significant changes so that they can be trivially disabled
6.2.2.2.2. When it comes to producing the product for a release, identify changes the team has not completed, and disable them with whatever means was chosen
6.2.2.2.3. We don't fall back, we push forward
6.2.2.3. An example for comparison
6.2.2.3.1. Commit graph of a feature that got merged second to last but doesn't work quite right, so a ton of work is done to pull all that code out (show troll crazy angry face) (1E)
6.2.2.3.2. Commit graph of a feature that didn't make it that is merged into the baseline with CI (2E)
7. In closing
7.1. Your code as a version
7.1.1. Commit graph of a project without CI
7.1.1.1. versioned progress
7.1.1.2. confidence colors
7.1.1.3. feature pulling fiasco
7.2. Your code alive (on mountain dew)
7.2.1. Commit graph of a project with CI
7.2.1.1. Steady progress
7.2.1.2. consistent confidence
7.2.1.3. disabling mechanisms
7.3. Review goals and identify where they are represented on the graphs
8. FAQ
8.1. Does this only work if there exists a good automated test suite on the project?
8.1.1. No, it helps even more
8.1.1.1. In fact this helps even more when there does not exist good automated tests. This means most of your testing is done manually. If you wait to merge at the end you have to repeat all manual efforts and re-troubleshoot very difficult problems while merging along the way, any manual tests done halfway through are done across that integration so you are gaining more and more confidence and more manual test coverage throughout the iteration.
8.2. When do we remove the extra and disable code?
8.2.1. When it makes sense
8.2.1.1. Once the team accepts the code and is ready to make the feature production
8.2.1.2. Once the risks of the feature are overcome
8.2.1.3. Once everyone feels comfortable with the burn in time
8.2.1.4. Basically when your team is ready
8.3. When do we peer review the code? Before disable code is removed or after?
8.3.1. Both
8.3.1.1. You will want a full review of the code before disable code has been removed so that the team can agree to move forward with the code
8.3.1.2. Then you will need a very quick/easy follow up review of removing the disable code and the extra tests