J'aimerais bien parler de l'intégration continue, mais après la lecture de la définition soumise par Mike Roberts et Owen Rogers le 19 Mai 2005, sur le site Internet CruiseControl.Net.
The practice of continuous integration represents a fundamental shift in the process of building software. It takes integration, commonly an infrequent and painful exercise, and makes it a simple, core part of a developer's daily activities. Integrating continuously makes integration a part of the natural rhythm of coding, an integral part of the test-code-refactor cycle. Continuous integration is about progressing steadily forward by taking small steps.
Integration should happen continuously, and continuously is more often than you might think. The frequency of integration will vary from project to project, from developer to developer, and from modification to modification. However, as a goal and a good rule of thumb, developers should integrate their changes once every few hours and at least once per day.
Learning how to integrate so frequently requires practice and discipline. Fundamentally, an integration can occur at any point when the code compiles and all the unit tests are passing. The challenge is learning how to write software so that you never stray too far from this point. If you are testing at the right level of granularity and are refactoring regularly, then you should never be more than a few minutes away from this point. This means that you are almost always in a position where you can launch a new integration.
Deciding when to integrate is all about controlling risk. When making modifications in a high traffic area of the code base or when conducting broad refactorings like class renaming or package reorganisation, there is an elevated risk of impacting other developers or of having merge conflicts when committing. The longer that developers go without integrating, the greater the likelihood of conflicts and the larger the effort required to resolve those conflicts. As the effort of integration increases exponentially in proportion to the time between integrations, best practices dictate that when making high-risk changes a developer should start from a clean workspace, focus only on required modifications, proceed with the smallest logical steps, and then commit at the earliest opportunity.
A successful integration is a measure of progress. It provides feedback that the new code runs correctly in the integration environment and successfully interoperates with the rest of the code base. Code sitting unintegrated in a developer's workspace simply does not exist. It is not part of the code base, it cannot be accessed by other developers or tested by the customer. Only when it has been successfully integrated is the benefit of the new code realised.
Personnelement, j'en suis ou exactement avec mon implémentation de CruiseControl.Net ? Il ne me reste qu'a écrire la tâche effectuant la compilation du site et le XCopy de la compilation des sources Asp.Net vers le répertoire de pré-production (preprod.leprogrammeur.net), et par la suite, le même système pour la copie vers le site de production (www.leprogrammeur.net). Pour le reste, tout ce qui touche à la couche d'affaire du site Internet, c'est fait, les tâches de compilation et de tests unitaire sont intégré.
Tout ça parce que j'en avait assez de compiler manuellement mon site Internet sur mon poste, de zipper les fichiers, d'envoyé par FTP, extraires les fichiers dans un environnement de préprod et ensuite copier vers la prod... Et si un problème survient, reprendre de 0. Utilisant VSS pour archiver mes sources, pourquoi ne pas automatiser le tout ? Pourquoi ne pas être conforme au standard ? Pourquoi ne pas prendre le temps pour en sauver d'avantage ? Il n'y à donc aucune raison à tout ces pourquoi ?
Soyez le premier à noter ce billet
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5