Continuous integration

Editor's Notes

• #2: Introduce the talk
• #3: Ask the questions :-Dev - Who hates arriving in on Monday and found the code does not compile?ITPro - Who enjoys installing new software onto the live servers?Management - Why does the dev team never the release right first time?Theory CI is just not about tools, it really is about discipline, mindset, collective responsibility, etc. The tools are really there to assist the team in becoming an effective team that practice CI well.Practices In martainfolwer’s article, which will be in this slide deck, he lists and discuses the 10 practices which, if followed, helps your team get the most out of CIDemo Manual CI This demo will take your through manual process of following CI, it’s really to give you a feel for the process and how tools can help speed things up a bitDemo This will show how to configure team city to do a SP 2010 build, complete with MSBUILD build script writing wwwoooooooBuild master I’ll finish up by talking about the build master role, and how it is important for a team to have this role.
• #5: Talk about the factory line Talk about what continuous integration is, and explain how is difficult it is to explain, however, the proof is in the pudding.People get it after you show them. People, may not see the need to install a build server, and build the software again on that box, what's wrong with building and testing software?
• #6: Before ci :-Developers have no idea whether or not the code they are committing is correct. Building the software for deployment, maybe to long and difficult.You will have less confidence in the code, whether building it, or deploying it.Generally nobody like deploying the code, because it is boring,reputationus, error prone, yet high profile. It goes wrong and ka boom.Never getting the deployment right first time make you look a bit, hence why you do not release all that much.
• #7: No excuses
• #8: Deployment is a no brainerBecause it is easy, no one minds doing it.You know how long the build will take, because you build and deploy a lot.
• #9: Should the “Configure Team City” be darker?
• #10: Everything in one place.
• #11: Get the computer to do the boring work for you, they love that sort of thing.Talk through MSBUILD scripts and other scripting languages.
• #12: The build should check itself, meaning it should confirm that the code builds, tests pass, code looks good, code is well covered, etc.
• #13: The dev team should commit code a lot, new code still on there dev boxes is waste, good practice to follow is if you are doing unit test, tdd, check in after each test passes. If you are not doing unit testing, which you should, then commit at a natural break. But still many times a day.
• #14: With the dev build the commit of code to the source code repos should cause a build, very important.
• #15: You need fast feedback, a slow build will mean you are hanging around for the build to finish, leading to ignoring it
• #16: Your integration system test should be as close to production as possibleRemove deployment issues to live.Greater confidence.
• #17: All build artefacts should be available.Testing team can use thisManagers evenOr anybody interested in installing and playing.
• #18: Feedback feedbackfeedback
• #19: Use computers to take away the boring thingsHumans hate repetitionLess error proneKnow quantity
• #20: Sprint 0Easy from beginningHarder to retrofit, no excuse to not do it though.
• #21: A green build is a good buildGreen build means that you can have confidenceEveryone is happy.
• #22: Mention the Skoda advert.
• #23: Talk about the solution structure
• #25: Remember to add this :-Reference Syntax: %env.MSBuild%Value: %system.DotNetFramework4.0_x86_Path%To the environment settings for the build config.
• #28: Build master is a distinct role.You must consider adding as a role.The build server is not fire forget, it grows with the project.
• #29: It is hardHigh profile
• #30: You may seem to nag all the timePeople may not unde3rstand way it is important, hence the parent analogy.
• #31: Everyone in the team should share the responsibilityThis means that everyone understands the build.