持續整合樣式：Single Shared Library Project

Dec. 29 20:41~21:02

昨天才提到 Installation Project 這個 pattern，今天 Teddy 在 Continuous Integration 這本書的 191 頁剛好看到一句話，可以呼應 Installation Project 的重要性 。這句話是這樣滴：

If you can't release your software, then it's almost as if it doesn't exist.

噯呀，辛辛苦苦熬夜爆肝所寫出來的程式如果沒有 release ，就好像女方好不容易懷孕但是男方不肯負責，只好去『夾娃娃』，而這個小生命最後等於不存在一樣的那種感覺。

揮一揮鍵盤，只帶走一個月 N 千塊的研究助理費，這不是 太棒  太可惜了嗎！所以，程式寫幾行不是重點，前人留給你多少 bugs 也不是重點，重點是軟體在你手中有沒有(能不能) release。

***

今天接這看 paper 裡面個另一個 pattern: Single Shared Library Project 。

Single Shared Library Project

Context: A software product is structured as a number of projects. These projects share some common libraries. For example, a software called ezMonitor includes both Java and C++ projects. In the projects written in Java, Apache Log4J is used. You also develop two common libraries for your application: FileCommons for file manipulation and NetworkCommons for network operation. Some of the ezMonitor projects make use of both libraries; some others make use of one of them and still others make use of none. One way to share the libraries is to manually copy them to the project workspace. However, doing so complicates the version control of the share libraries. For example, once a shared library needs to be upgraded, each of the local copies needs to be upgraded as well. This can be error-prone and tedious for a product that has a number of projects sharing common libraries. 
 
Problem: How do we make share common third-parity and in-house libraries among projects easy?

Forces:

• You want to use a single version of a shared library among the projects that use the library.
  
• Shared libraries, either third-parity or in-house, are likely to change over time.
• The version control mechanism for shared libraries should be as easy as possible. 
   
  

Solution: Create a project that acts as a centralized repository for shared libraries. Organize the project structure in a way that third-parity libraries, in-house libraries, native (platform-dependent) libraries as well as system drivers, and source code of the libraries (if available) are placed in different folders. Define rules for each type of the libraries: (1) how should these libraries be referenced by other projects; (2) when and who can update a new version of a library; and (3) how does the library update process get initiated (e.g., manually or automatically).

Figure 2. An example of a Single Shared Library Project

Fig. 2 shows an example to organize a Single Shared Library Project named SharedLibraries. The SharedLibraries project acts as a centralized repository for a cross-platform product written in Java and C/C++. There are six different folders in the SharedLibraries project:

• driver: This folder contains system drivers, primarily for Windows operating systems. Usually, a Windows system needs to be rebooted to enable the driver.
  
• native: This folder contains platform-dependent libraries (usually .dll files for Windows and .so files for Linux-based systems) or executable utility programs (e.g., the cfg_x64 program in Fig. 2).
  
• in-house: This folder contains the binary code of common in-house libraries that will be used by other projects. For example, if the MyServer project needs to use the FileCommons.jar file, it does so by directly referencing FileCommons.jar from the SharedLibraries. Whenever the FileCommons.jar is updated to a newer version, the MyServer project (and all projects that use the FileCommons.jar) can get the latest version of the FileCommons.jar by simply issuing an “update” command to sync its local data from the code repository.
  
• in-house-src: This folder contains the source code of common in-house libraries. The main purpose of placing library source code in the SharedLibraries project is for debugging and tracing. When everything goes well, developers usually do not want to know the internal implementation of a library. However, when things go wrong and an exception is raised, developers may need to locate the problem by following the stack trace. In this situation, jumping into the source code along the stack trace is necessary. If the stack trace contains an invocation to a method in the library, developers need its source code to explore the method implementation. An IDE (Integrated Development Environment) like Eclipse allows developers to link the source code of a library to its binary code so that Eclipse can jump into the implementation of the library while debugging.
  
• 3party: The function of this folder is similar to the in-house folder except that this folder contains libraries from third-parties.
• 3party-src: The function of this folder is similar to the in-house-src folder except that this folder contains source code of third-party libraries.

Resulting Context: One drawback of sharing libraries via a Single Shared Library Project is the “timing” issue when this pattern is applied in IDEs. Suppose that you use the Eclipse IDE to modify code in project A and project B at the same time and project A uses code in the project B. If project A references code in the project B via a Single Shared Library Project, modification in project B cannot be reflected immediately to project A. Modification in project B can be reflected in project A only after (1) a jar file (i.e., the library of project B) is generated and committed to the Single Shared Library Project; (2) project A syncs with the Single Shared Library Project. Thus, if a set of projects is close related, a Single Shared Library Project may not be suitable. In this situation, use project references in your IDE instead. A project reference example is shown in Fig. 3. In the continuous integration system site, the Single Shared Library Project can still be used since project A is built after project B according to their dependency relationships. 

Figure 3. A screenshot of the Eclipse project reference.

 

Related Patterns: The build outcomes of Platform Independent Projects, Interface Projects, and Native Projects are stored in a Single Shared Library Project.

先這樣，明天繼續。

***

 友藏內心獨白：花不到 30 分鐘又寫了一篇，YES。