Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

NOTES - Build for Disable Preso - NOTES by Mind Map: NOTES - Build for Disable Preso
0.0 stars - reviews range from 0 to 5

NOTES - Build for Disable Preso - NOTES

Build for Disable Techniques

Simple if check with a static boolean

Code example

Add a method for the alternate way and static boolean

Code Example

Writing tests could be challenging as you enable and disable., 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.

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

Code example

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.

Actually USE interfaces!!

Decorator Pattern, Code example, Tests and class can stay in place if desired. Sometimes this is a good design, sometimes not.

Leads to better coding practices in general

Sometimes you find out, this is better architectually and that functionality shouldn't be mixed in where it was.

Writing code in separate and distinct groups is easier to test, easier to maintain.

The Goals

I want you to be productive... every day

I want you to give you options on how to stop fearing merging and how to start improving your product confidently

I want you to stop thinking of your code as a version and start thinking of your code as a living entity

Presenter Info

Nicholas Tuck

This preso url:

twitter: @nicholastuck

Find me on G+ (not kidding) seriously...

Preso Title: Your Code is Not a Version: How 'Build for Disable' can bring you true continuous integration

The Room for Improvement (room picture?)

Commit graph with feature branches (1a)

This might be how you integrate with your team

A couple features might be done in the middle, Most merging is happening at the end, If you use git or mercurial this week sucks, If you use cvs or svn this week you try to work up the courage to quit, This is a workflow that you can make work, but it's not productive, Usually this requires everyone on the entire team to work together, this is hard to do when we didn't work together on the features. Often times it requires the most knowledgable guy on the project to do the merges to keep things straight, What a waste of that guys time. If you have to actually fix something do you do it halfway through merges or do you merge all of it and deal with the fall out., You think if you merge first your fine, no worries, so get your stuff done early right?, Not right. When everyone else merges all week, your stuff stops working because they merged in their favor and did what they could to make your tests pass... you wrote tests right?, Ontop of the difficulties actually developing, this means all testing done on feature branches have limited value, We have to redo all tests we did all sprint. Ideally these are automated unit and system level tests, but many of us just aren't there yet to have fully automated suite that we have full confidence with., commit graph with confidence colors on public repo. Green at first merge, yellow to green at second merge, yellow at third merge, and red at final merges. (1b), Usually this integration adds bugs that were already fixed individually, but have been reintroduced due to the complications and last minute testing.

Commit graph with highlight of duplicate work (1c)

You ever write the same code or fix the same problem that someone else did?, 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

It's not just about duplicate work, we could actually be helping eachother., 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

Some of you have processes that you should pull and merge every couple days. I agree you should pull and merge daily., 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.

Commit graph with a release and all the features that didn't make it (1c)

Have you ever written a major feature but just didn't make the cut off?, 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, These constant daily improvements are not making into our releases and that's not good., Show improvement line graph of choppy up lines as branches are merged at different levels of improvement (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.

Simple Solution

Commit hourly and push daily

This is not just DVC commit hourly, this is actually push to the public repo daily

It's really not a novel idea, it's the obvious ones

Commit graph with constant pushes and merges (2a), What does it mean?, 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., Fixed a small bug thats a handful of lines of code. Write the test and push the code, Working a big feature that will take days, maybe weeks, write a couple hours worth and push it to everyone., How is this an improvement?, When you push daily you merge daily., There is no more nightmare merges regardless of what version control you use... Though if you use git or mercurial you can start to enjoy your job again., Continuous testing., As you constantly integrate with eachother your tests are constantly testing the integration., Any integration problems are found early and fixed easily. All the while more tests are being added across the integration points, Confidence is incredibly high at the end of a sprint because nearly everything has been tested for weeks. The only risk are the final changes which you can focus on and easily test without needing to retest everything, commit graph comparison with confidence colors. All green until the last merges make it yellow (2b), Your application is ALWAYS improving., No longer does your application improve in versions., Your get a constant rate of improvement on the project at which any point you make your next release, it will be significant., continuous improvement graph vs versioned improvement graph (3), To do this we have to break some developer taboos you were taught but never fully understood, taboos, Never commit code that doesn't fully work, Let's not kid ourselves, everything we work on doesn't work in one way or another. They are called bugs, all apps have them., We work daily with features that don't fully work that we are unaware of which is much harder than working with features that we know don't work yet., The unknown is hard to work with, the known is easy to work with, This really isn't a big deal. We are working all of these features, it will get fixed. We could actually work as a team on anything. If something doesn't work and you need it, fix it. Old bug, new bug, current featuure, let's work together, This does require we are talking to eachother daily as a team. I bet many of you here are having daily standup meetings where 15 min a day you say what you're working on. That's how you keep on the same page to work though any conflicts, Never commit commented code, We are afraid of commented code because it never goes away becase no one knows anything about it., We are not changing the attitude, if no one knows anything about the commented code, get rid of it., But with this ci approach, we know about it, we are working it, it will get cleaned up tomorrow., As we code daily, we are constantly commenting code, copying code, uncommenting code, adding TODOs. WE ALL CODE THIS WAY. (maybe example of same line commented for each to for x?), Lets not try to hide this and simply embrace it. It's okay to push todos and commented code, as long as we are always working on making it better and we clean up after ourselves, rules you want to re-enforce, Don't break the build!!, Add ignore annotations or comment out failing tests, it's okay as long as you don't break the build., We still want a broken build to flag a problem; but a feature you are in the middle of is not a problem, it's progress, Maybe implement rollback in jenkins if a build breaks

Why Isn't Everyone Doing This? Introducing 'Build for Disable'

The reason why you don't see more teams doing true continuous integration is because we believe our code exists in versions

Show commit graph of feature branches and every merge is versioned (1d)

We have hammered into our heads we are working for weeks to deliver an idealized version of our code to production, 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., Code, with a cape, in a first place stand, We try to have the public repo represent perfect versions of the code because that makes us feel warm and fuzzy inside., 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, We need to develop our process and find a tool that works, 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., Show commit graph where branch feature doesn't make it, simple mitigation, no complications. (1a - double sided tape R), 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, We try an hg rollback, revert, bifercate mulligan and hope the dice roll sevens, Plus we ignore the iminent problem that awaits us the day after the release when we try to merge in the mess we just made worse, 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

I have a solution

Your Code is NOT a Version!, Your code IS a living entity., It is always improving, it is always moving forward, it's always changing., 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., 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

Introducing 'Build for Disable' (Also called Branch by Abstraction VS Branch by Source Control) (Similar to Feature Toggle), 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., What is it? It's a simple idea, Build significant changes so that they can be trivially disabled, disabled can mean, a simple boolean calls the old code instead of the new code, a few lines of code are commented to remove an enhancement, the gui is hidden from the user preventing use of the code, 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, We don't fall back, we push forward, An example for comparison, 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), the last feature starts failing because it relied on the previous, tests are failing, confidence is decreasing, productivity has halted, time is being wasted, Everything has to be retested, fixes have to be added, more merging will take place. This is a nightmare., Show commit graph with lots of commits and merges over time and show the changes taking a couple days, our tools help support these undos but it's still never easy and rarely successful. This is another example of us forming process around our tools., Commit graph of a feature that didn't make it that is merged into the baseline with CI (2E), Here's what we did: Picture of the menu with 3 buttons one commit (all the code added '//'), and picture of the menu with 2 buttons the next commit, That's it, simple as that, 1 single line of code commented out and we are done, Show commit graph with one commit, tag of release, and timeline of 10 minutes, 10 minutes is Jenkins building it and running all of our integration and system tests, But Nick all of that code is in there, it's going to production how can you be sure it's not going to affect anything?, It will affect the product... isn't it great? So many improvements will be going out with the release. We wrote the code, we know what works and what doesn't (as much as we will ever know), we know where to disable the feature., Everything at this point was still tested, everything that we knew passed continues to pass, we have high confidence in our product, such a small change has mitigated real risk while our previous mitigation behavior to rip out all code ever dealing with an incomplete feature added more risk than any benefit it may have offered

In closing

Your code as a version

Commit graph of a project without CI, versioned progress, confidence colors, feature pulling fiasco

Your code alive (on mountain dew)

Commit graph of a project with CI, Steady progress, consistent confidence, disabling mechanisms

Review goals and identify where they are represented on the graphs


Does this only work if there exists a good automated test suite on the project?

No, it helps even more, 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.

When do we remove the extra and disable code?

When it makes sense, Once the team accepts the code and is ready to make the feature production, Once the risks of the feature are overcome, Once everyone feels comfortable with the burn in time, Basically when your team is ready

When do we peer review the code? Before disable code is removed or after?

Both, 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, Then you will need a very quick/easy follow up review of removing the disable code and the extra tests