Continuous_Integration_and_Deployment汇.ppt

Continuous Improvement This is a process that will evolve. It won’t suddenly be perfect and then no longer change. It’s going to take time and effort to make the first few steps, and there will be many more steps to follow. Like with all parts of our development process we need to constantly look at what’s working and what can be improved. * So what our new improved process look like? * What might a continuous integration and delivery process look like? TALK through Peter McLaren’s pipeline picture – see included PNG image. * Before we introduce such a process, there’s a few pre-requisites. We have the first two. And hopefully we can get the agreement of the team as we discuss this more. * The most important practice for continuous integration to work properly is frequent check in to trunk. Preferably a couple of times a day. There’s a number of reasons for frequent check ins. If the change is small it is less likely to break the build. That means in the event of a problem, it should be easier to fix, or you can simply roll back to the previous working version and try again. It also means that you’re less likely to have major conflicts with other people’s work. If everyone is making small changes these conflicts become apparent earlier and so take less time to resolve. We also should continue to check into truck, rather than branches. Otherwise all we’re doing is storing up the problems for later. * There also needs to be a pre check in process. The developer needs to ensure they have a local copy of the code from the latest working build plus their changes, and then run the build and commit tests locally. Only if this succeeds should the code be checked in. The developer should also wait for the automated build and commit tests to run successfully before starting on the next piece of work. Of course if they fail they’ll need to fix the build first. * After the check in an automated build process should then occur. We want something that