Let's say I'm working for a big company, we can call it X. Main task - try to implement Continuous Integration on existing projects which don't have it and try to improve those that do, but are having problems using it.
Ok, so let's start things with the obligatory link: Continuous Integration (courtesy of Wikipedia).
So, the theory goes like this (best case scenario, of course):
1. P.M. Boss finds out what needs to be done
2. P.M Boss writes a specification for it (or maybe J. Developer writes the spec)
3. J. Developer write some tests which describe basically what the application needs to do
4a. J. Developer writes the code that actually does stuff
4b. and he makes sure that the tests don't fail
5. J. Jr., trying to fix a bug in the initial implementation or to add new features writes new code and makes sure that the new code doesn't make tests fail!
Steps 1 and 4a are what happens in every programming task. Somebody finds out what needs to be done, someone does it. Business as usual.
However, for programming, where you have lots and lots of complex interactions the rest of the steps are highly recommended.
Step 2 usually means that you need program/product/project manager or an analyst to write the specs, step 3 means that you need testers or you need to allocate some time for testing to each of the developers.
So you already found a problem of Continuous Integration - testing. For each test written, someone could have code that actually did stuff that customers wanted and paid. However, luckily for me, this is not my domain of expertise (although I'm trying to learn about it too :) ).
And the second problem is automation. Sounds easy, should be easy, since all the people involved in the project are programmers, so they know everything there is to know about automation, right? Well... not really :)
In the next episode, we'll talk about Continuous Integration in the Java world, Part I - tools.
Ok, so let's start things with the obligatory link: Continuous Integration (courtesy of Wikipedia).
So, the theory goes like this (best case scenario, of course):
1. P.M. Boss finds out what needs to be done
2. P.M Boss writes a specification for it (or maybe J. Developer writes the spec)
3. J. Developer write some tests which describe basically what the application needs to do
4a. J. Developer writes the code that actually does stuff
4b. and he makes sure that the tests don't fail
5. J. Jr., trying to fix a bug in the initial implementation or to add new features writes new code and makes sure that the new code doesn't make tests fail!
Steps 1 and 4a are what happens in every programming task. Somebody finds out what needs to be done, someone does it. Business as usual.
However, for programming, where you have lots and lots of complex interactions the rest of the steps are highly recommended.
Step 2 usually means that you need program/product/project manager or an analyst to write the specs, step 3 means that you need testers or you need to allocate some time for testing to each of the developers.
So you already found a problem of Continuous Integration - testing. For each test written, someone could have code that actually did stuff that customers wanted and paid. However, luckily for me, this is not my domain of expertise (although I'm trying to learn about it too :) ).
And the second problem is automation. Sounds easy, should be easy, since all the people involved in the project are programmers, so they know everything there is to know about automation, right? Well... not really :)
In the next episode, we'll talk about Continuous Integration in the Java world, Part I - tools.
