Deployment Phase I - Deployment decisions
Deployment Phase I - Deployment decisions
Phase I focuses on making decisions about the Klocwork deployment. During this phase, several stages of planning are involved. You can use the Deployment Phase I worksheet to record your information.
Stage 1: Identify key staff
The success of a Klocwork deployment project will be determined in large part by the staff leading the effort. While the use of Klocwork will lead to a long-term reduction in costs, the initial deployment effort requires a part-time commitment from the following people:
- Klocwork Champion/Sponsor: Usually a manager or management team who is able to schedule the staff needed to assist in the Klocwork deployment. This person should be able to promote the use of Klocwork to additional groups and should be well versed in software development metrics.
-
Klocwork Administrator: This could be one person or a team, depending on how large your organization is and they will be responsible for performing Klocwork administrative tasks such as:
- Managing the Klocwork Servers
- Migrations and software updates
- Backing up the Klocwork database
- Configuring access permissions and roles
- Managing the checker sets and taxonomies
- Initially, the Klocwork Administrator(s) may also set up and manage the Klocwork integration builds for each project
- IT Administrator: Individual in the IT department who will set up the necessary system hardware, grant access to the authentication system and potentially manage the license server.
- Project Team Lead: For each development team that will use Klocwork, a team lead should be involved in establishing the parameters within which the process will function. For example, this individual will choose which checkers will be run, tune the knowledge base to ensure the best possible results, and act as an internal point of contact for the team.
- Developers: To ensure a successful deployment it is vital that the ultimate end-users, the developers, or a suitable set of representatives for them, are involved in the deployment decisions and process. Ultimately, the success of any code quality, security or compliance enforcement project is going to heavily depend on adoption of the rules by the developers at the point of maximum efficiency - the desktop - so any obstacles to this goal must be minimized. There are a number of training options (classroom based or computer based) to ensure that desktop usage patterns and best practices are effectively communicated.
- Quality Assurance, Security, or Compliance Team(s): Lastly, to ensure that any final deployment meets the needs of any quality, security or compliance requirements, it is important to have the relevant stakeholders involved in the deployment process and in particular in relation to the permissions and roles options for users and the resulting reports, audit trails and controls.
Klocwork Professional Services will help guide the specific requirements and will mentor these key staff members throughout the deployment phase.
Stage 2: Identify pilot projects
To limit the impact of any initial setup problems, it is recommended that Klocwork is piloted on one or a few smaller but representative projects to begin with. It may also be beneficial to keep these users within just one geographical location initially.
Stage 3: Deployment type
Although there are no decisions for this stage of deployment, it is important to note where Klocwork fits and the terminology needed to move forward. The following diagram illustrates where Klocwork is used in the software development life cycle (SDLC):
Klocwork is typically deployed into the SDLC using both the Developer desktop and Build analysis for proper usage. Below are the definitions:
- Developer desktop — Klocwork is used at the desktop, where developers will use it within their IDEs or on the command line. This scenario addresses issues immediately while developers are coding, thereby maximizing the return on investment.
- Build analysis — Klocwork is integrated into the full integration build, typically on a nightly or weekly schedule, at which time all components of the software system are compiled and linked into a finished software product.
Klocwork recommends deploying Klocwork at both the developer desktop and the integration build as this is the optimal deployment method and the most effective way to achieve maximum return on investment.
Deploying Developer Desktop and Build Analysis
These should be separated. Start with integration build analysis.
- Run a build analysis on the integration project: C/C++ integration build analysis - Cheat sheet
- Set up and run Klocwork on the developer desktop: Fixing issues before check-in with Klocwork Desktop Analysis
The first step is to run an integration build analysis. You will integrate Klocwork into the build process at the desired interval. Now, Klocwork Static Code Analysis will be used for management or reporting.
The second step is to set up the developer's desktop. This involves setting up the Klocwork plug-ins in the supported IDEs or using it on the command line. The key step here is that developer's will synchronize their environment with an integration build in step #1.
As long as the build analysis is maintained and developers are fixing the issues at the desktop, no outstanding issues will be found after code check-in.
Stage 4: Basic deployment structure
It is recommended that the ultimate structure of the Klocwork deployment is considered as early as possible in the process. You need to decide which Klocwork components will be installed and how the installation will be configured, including whether dedicated hardware is required.
Many of the initial deployment questions, such as: Will this be a multi-site deployment, where are the users going to be based, where will the servers ideally be based, do you have a corporate FlexNet Publisher server and will you want to use this existing server to manage the Klocwork licenses, are relevant.
- Klocwork Servers — these are the machines acting as the collaboration and collection point for all Klocwork data. Require capabilities will depend on the number of connected users and projects. However, Klocwork Servers will generally need to provide high availability, the ability to potentially handle many database transaction requests in parallel, and sufficient storage space for the data store. Klocwork Servers can be used to serve just a project team for smaller installations, through to business units or single locations, through to one server for the entire, global organization. Klocwork Servers consist of a database, a web server, and an optional license server and authentication server. Klocwork Servers themselves are unlicensed.
- Klocwork Build Servers — these are the machines that will produce the Klocwork integration build analysis. As with standard project build servers, Klocwork Build Servers will require a precise installation of the definitive project environment, to ensure that the results are accurate, and faster (more processing power) is generally better. For this reason, Klocwork Build Servers are often just an additional installation of the Klocwork server build tools on to an existing machine. This also applies for CI build systems or distributed build systems.
- Klocwork Desktops — these are the developer workstations, either stand-alone or connected to a Klocwork Server project, that perform the local analysis. With a connected project, it is possible to then perform a partial desktop build and make use of any central project analysis data from the Klocwork server. The desktop machines will generally have the normal project build tools and environment installed already, although when these build tools are held remotely on a central build server, the Klocwork desktop analysis components will follow suit.
- License Server — the license server for Klocwork licenses can be optionally installed separately, or make use of an existing corporate FlexNet Publisher server.
- Authentication Server — Klocwork Servers, and hence all related and interacting Klocwork tools, can be optionally connected to a corporate LDAP, ActiveDirectory or NIS server.
- Other systems, such as bug tracking systems, ALM/PLM systems, SCM systems and/or management information and dashboard utilities can also be connected to Klocwork via various APIs but these are less tightly integrated and hence have no significant impact on the basic deployment structure.
Notes for installation
For installation, the minimum requirements can be found in the System requirements.
In addition, special consideration should be taken for:
- installing server components on multiple machines
- installing multiple projects_roots
- choosing distributed analysis
- controlling access to Klocwork (including setting up NIS or LDAP)
- licensing
Additional hardware considerations for Large deployments
If you are using parallel processing or multicore processing, then you should allocate a minimum of 2 GB of memory per processor/core. More than 2 GB may be required for very large analyses. Note that the size of a build and its RAM requirements depend not only on the lines of code, but also on the number and complexity of relationships in the code. Additionally, Klocwork has shown better performance with multiple core processors. This can significantly improve database performance.
Stage 5: Additional large-scale decisions
- Only the connection between the Klocwork Build Servers and the Klocwork Server requires any significant transfer of data — while the integration build analysis results are being loaded to the database. For this reason, where possible, Klocwork Build Servers and Klocwork Servers should be co-located, or at least provided with a substantial network connection.
- The connections between the Klocwork Desktop machines and the Klocwork Server, the License Server and the Authentication Server require comparatively little bandwidth.
Stage 6: Choose build integration type
Klocwork analysis requires integration into an organization's existing build system. Integration builds are usually done through a build system (ant, make, etc.) or with an IDE (Visual Studio, CodeWarrior, etc). To ensure accurate Klocwork integration build analysis results, Klocwork requires a complete understanding of how the software is compiled and linked, in the form of a build specification.
For details on build integration, see Creating a C/C++ build specification, Creating a Java build specification or Creating a C# build specification.
With a build specification, the Klocwork build analysis can be executed. Klocwork build analysis can be distributed via support for parallel and distributed execution. See C/C++ integration build analysis - Cheat sheet for details. The method used will depend on the environment, build system and language.
Stage 7: Choose issues/vulnerabilities to be detected
At this stage, technical leads and managers must decide which issues and security vulnerabilities to enable. Large development environments with mature code bases may consider selecting only a handful of issues or vulnerabilities to begin their analysis, expanding the number of issues enabled on an iterative basis.
You can even organize your own set of Klocwork checkers between analysis runs and make the new organizational structure immediately available for reporting. We call this organizational structure a taxonomy.
You can also download additional taxonomies and checkers for many well known industry standards, such as MISRA, CERT, CWE, and DISA STIG. To use these checkers, you need to download them from https://library.roguewave.com/display/SUPPORT/Klocwork+-+Product+Downloads. See the readme file included with the download for details on enabling the MISRA checkers.
A good place to begin is with Klocwork's default configuration, which can be expanded or reduced. This will allow your organization to focus its early detection efforts on the issues and vulnerabilities that are important to your organization.
Many organizations will begin their analysis on issues such as memory leaks, buffer overflows and null pointer dereferences. Other organizations may be more concerned with security vulnerabilities and will focus on detecting issues specific to security. For example, if you are developing embedded software, you may consider enabling low memory condition rules. But if you are developing desktop client software, you may want to consider turning this off initially. Finally, some organizations may only concern themselves with compliance.
For Java code, select one of Klocwork's pre-defined Java profiles that are tuned to particular types of applications, including web applications and others. Klocwork Professional Services will help you understand what is important and will direct you with the specific issues and vulnerabilities for your product.
Stage 8: Choose issue management approach
A key element to successfully using automated source analysis is to implement a process for managing reported issues and vulnerabilities over time. Klocwork tracks when the issue or vulnerability was found (state), and what action was assigned to the reported problem (status). It stores this information in a database to provide the information across builds.
States are automatically assigned to every issue and vulnerability found by Klocwork.
Status can be assigned by users to every issue and vulnerability found by Klocwork. For example, the status can be used to identify what will be classified as an issue that needs to be fixed immediately versus issues that may be safely ignored, either temporarily or permanently.
An agreement on how the various statuses will be used by your organization is necessary for issue management.
You will also have the option to baseline a project so that any existing issues found within legacy code by whatever checkers you select will be possible to put to one side, allowing you to focus on preventing any new issues from reaching the code stream.
Stage 9: Choose role-based security (optional)
Once your organization has decided which statuses you will use, and what each status means as part of the process, you will also need to decide who can change issue status. For example, you may allow only certain lead developers or reviewers to change status to "Not a problem", requiring developers to set the status to "Defer" and reviewers to validate that everything set to "Defer" status is really not an issue before changing status to "Not a problem".
Klocwork provides several ways to control the use of Klocwork based on roles. Examples include: Would you want all developers to build Klocwork projects? Would you want all junior developers to be able to change any status from "Analyze" to "Not a problem"? Klocwork provides flexibility to customize this on a per-user or per-group basis.
The following image shows a typical developer workflow:
In order to implement role-based security, you must first identify users and groups in the system. If you do decide to implement this feature, it is recommended that you either integrate with your existing LDAP or NIS infrastructure. You can also use Klocwork's built-in access control.