MSDEV is the name of the DevStudio IDE executable. These constraints led to the decision to write scripts that manipulated MSDEV via its command line interface.
Development was being done using the ATL wizard which generates complex project files, and templated code that is managed by the IDE.
Developer's were all using the MS DevStudio IDE for development and building. We had to retrofit the build process onto an existing code base. When we began implementing CI for this project several constraints confronted us immediately: These were checked out and built just like our project-developed code.Īs noted above, the first step in getting a successful build, is actually building the code. We did keep other third-party libraries in the repository. Also, this ensures that as updates and Service Packs are issued by Microsoft, they can be installed across all development and build machines consistently. For pragmatic reasons, it was easier to make all machines conform to this standard, than to extract the library code needed from these SDK's. Since technically these SDK files are part of the "source" we had considered placing them with the rest of the code base in the repository. 
Current version of Microsoft XML Parser. Current version of Microsoft XML Parser SDK. Current Version of the Microsoft Platform SDK. We found the following were best installed prior to introducing a machine to our project: Because of this, we found there is a minimum standard setup that a target machine had to have in addition to being "clean." These files must be installed into the correct folders, discovered by the build process in a consistent order, and registered properly. One issue that presented additional difficulty using Visual C++ was the location of SDK libraries and binaries. If all of these steps completed without error or failure, we had a successful build. Acceptance tests marked as part of our BVT had to pass at 100%. All unit test suites (which exercised the code both via COM interfaces, and native C++ interfaces) had to pass at 100%. All external services, started and ready to go. The database (SQL Server 2000) had to be built from scratch and populated with test data. COM and COM+ objects had to be registered with the operating system. Every binary had to be compiled, linked and deployed for loading. All the latest source files had to be checked out of the source code repository (in this case, StarTeam). All binaries had to be built and deployed:. These are the actions we identified that needed to happen for us to have a successful build: Thus, one of the keys to successfully implementing CI with C++ is dependency management. As in all C++ projects, dependencies have a great impact on build time. If it takes too long to build, people are likely to avoid doing so, and the benefits of CI are lost. As time between builds increases, it is more likely that a dependency will change requiring more dependant files (and in VC++, dependant projects) to be rebuilt. 
The build time on a development machine can be lengthy if one waits more than half a day to integrate, and every hour is not too often. This is especially true when developing with C++. Here we will outline how we've implemented CI in a COM/Windows environment for a project developing primarily in Visual C++.Īs noted in the main article, one of the least intuitive notions about integration is that less often does not result in less difficulty, it results in more difficulty. Variables such as language, platform, team size & team location provide unique implementation challenges.
While the principles remain largely unchanged from project to project, the implementation of this practice can vary considerably. The Continuous Integration principles are applicable in many different development environments. RSS Continuous Integration with Visual C++ and COM
0 kommentar(er)
