************ [RÜPING-2003], Chapter 1 **************************************************************
Documents describe us...
Roadmap diagram of Patterns: it sketches the patterns and relationships that hold between them.
Target Readers: To ensure ...
Big Picture: People can be introduces to a project without being confronted with a deluge of technical details by
describi...
Four features required for CI:
1. A connection to a version control repository
2. A build script
3. Some sort of feedback ...
Upcoming SlideShare
Loading in...5
×

Reading Summary - Agile Documentation + Continuous Integration

71

Published on

[RÜPING-2003], Chapter 1
[DUVALL-2007], Chapter 1-3

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
71
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Reading Summary - Agile Documentation + Continuous Integration

  1. 1. ************ [RÜPING-2003], Chapter 1 ************************************************************** Documents describe user requirements, software architectures, design decisions, source code and management issues. Documentation can contribute to the success of a project by making necessary information available to the team members. It can preserve knowledge within a team, and prevent the team from re-inventing things when team members leave and new people join. It can capture expertise gained in one project and make it available to future projects. When knowledge has been committed to paper, it cannot be lost. “Documentation in moderation, aids communication, enhances knowledge transfer, preserves historical information, and fulfils governmental and legal requirements.” –Highsmith Light-but-sufficient approach is favorable because:  Such approach prevents the project team form expending unnecessary large effort on documentation  Light-but-sufficient documentation is more accessible, and therefore more useful, for a team than voluminous documentation “Quality is more important than quantity in project documentation.” / “Documentation is a means, not an end.” A pattern in this sense is essentially a well-proven problem-solution pair, presented in a structured form. Users can look up patterns for their particular problems, apply the solutions, and thereby draw on the general expertise available. A good pattern describes the forces that are associated with a problem, those issues that influence or constrain possible solutions. A pattern offers the rationale behind the solution. Contrast of the Role of Documentation with Face-to-Face Communication
  2. 2. Roadmap diagram of Patterns: it sketches the patterns and relationships that hold between them. Target Readers: To ensure that the documents that the project team produce will be appreciated, each document must have a target leadership, and must address these readers in order to prove useful. Focused Information: Documents can be prevented from meandering and getting nowhere by having a clear and identifiable focus on a particular topic, making it concise and straightforward. Individual Documentation Requirements: Unnecessary documentation requirements can be avoided by defining documentation requirements individually. Documentation Portfolio: Teams can reuse the knowledge about which documents might be required in their projects by using a documentation portfolio that describes which documents might be necessary in software project, and their scope. In an organization sets up such a portfolio, projects can choose those documents they need, checking the necessity of each candidate document individually. [Management, Specification, Design, Migration, Test, Usage, Operations] Focus on Long-Term Relevance: Projects can avoid producing documentation that expires too soon by making documentation that focuses on issues with a long-term relevance, issues that will play a role in a later project phase or in future projects. Specification as a Joint Effort: Development projects can ensure that they head in the direction the customer wants by doing specification based on the requirement analysis done jointly by the project team and the customer. Design Rationale: Team can make sure that the foundations are laid for future design changes by making design documents not restricted to describing the actual design, but also focus on the rationale behind the design and explain why the particular design was chosen.
  3. 3. Big Picture: People can be introduces to a project without being confronted with a deluge of technical details by describing the ‘Big Picture’ of the architecture that underlies the system under construction. Separation of Description and Evaluation: Authors can prevent loss of credibility by clearly separation description from valuation in their documents. Realistic Examples: Abstract material can be explained in a comprehensible way if the project documents include realistic examples from the project’s context. ************ [DUVALL-2007], Chapter 1-3************************************************************* What is continuous integration? A software development practice where members of a team integrate their work frequently, usually each person integrates at least daily- leading to multiple integrations per day. Each integration is verified by an automated build to detect integration errors as quickly as possible. This approach leads to significantly reduce integration problems and allows a team to develop a cohesive software more rapidly. Rapid Feedback: Continuous integration increases opportunities for feedback. Through it, we learn the state of the project several times a day. CI can be used to reduce the time between when a defect is introduces and when it is fixed, thus improving overall software quality. CI works well with practices like refactoring and test-driven development, because these practices are centered on the notion making small changes. What is a Build? It is a compile that may consist of the compilation, testing, inspection, and deployment. A build acts as the process for putting source code together and verifying that the software works as a cohesive unit. ‘Find problems earlier by building often.’ The purpose of Version Control Repository is to manage changes to source code and other software assets (such as documentation) using a controlled access repository. A CI server runs an integration build whenever a change is committed to the version control repository. The CI server will retrieve the source files and run a build script or scripts. The Build Script is a single report, or set of scripts, you use to compile, test, inspect, and deploy software. It can be used without implementing a CI system. One of the key purposes of CI is produce feedback on an integration build. Integration build machine is a separate machine whose sole responsibility is to integrate software. It hosts the CI server, and the CI server polls the version control repository.
  4. 4. Four features required for CI: 1. A connection to a version control repository 2. A build script 3. Some sort of feedback mechanism (such as e-mail) 4. A process for integrating the source code changes (manual or CI server) Compilation involves creating executable code from your human-readable source. By using CI system, the integration of the database can be ensured through a version control repository. The database source code—Data definition language scripts, Data manipulation language scripts, stores procedure definitions, partitioning, and so on—in the same manner as any other source code in the system. Different categories of tests run from a CI system to speed up the builds. These categories may include unit, component, system, load/performance, security, and others. Automated code inspections (static & dynamic analysis) can be used to enhance the quality of the software by enforcing rules. Continuous deployment enables delivering working, deployable software at any point in time. Meaning a key purpose of a CI system is to generate the bundled software artifacts with the latest code changes and make it available to a testing environment. Concise code with well-chosen class, variable, and method names (for instance) is the best documentation. Ci system can use tools to generate class diagrams and other information, all based on the committed source code in the version control repository.

×