Understanding the Software Pipeline
Software development is a highly collaborative process which requires customer input, planning, development, and product testing. The application infrastructure which underlies the Software Development Lifecycle (SDLC) should support this collaboration and provide traceability and transparency. These tools should provide a foundation for taking software from the initial idea all the way through to release. In order to establish traceability, each phase of the development process should capture structured data which can be linked to the other phases of development.
The diagram below illustrates the interconnected nature of the software development process. Once an idea is formalized into a requirement, it must then be implemented in software and packaged for use, before finally being tested and released to a customer. Each of these phases may require unique software capable of managing the information associated with that stage of the software lifecycle. It is this interconnected feedback loop which ultimately forms the relationships between each phase and which provides transparency to the development lifecycle.
Establishing links between the software development phases is a critical requirement for establishing traceability and transparency. As business analysts meet with customers and collect software requirements they must capture those requirements. Developers must then implement each requirement to ensure that the software product meets the needs of the customer. Testing organizations must test the software against these requirements to ensure that the product was implemented as requested and functions correctly. During each of phase of development, information about the project must be represented as structured data, and each piece of data must have a relationship with information in other phases. The integration between these software development tools provides visibility into the scope and progress of a project within the software development lifecycle.
Knowledge Management
From the initial conception of a software product, there is some descriptive representation of how that project will be developed, where it will reside, and who will participate in its development. These ideas and organizational pages provide a collaborative platform for members of the project team to publish information and keep track of project information. This is often the least structured and least integrated portion of the software development process, but it is still important to have a central repository where project knowledge can be easily shared and updated.
Requirements Management
Software requirements are the definition of how a software product should behave. Requirements come from many different sources. They can come from customer input, product management, software developers, or domain experts. They should represent a description of a product feature or behavior that is meaningful to an application user. These requirements may have varying priorities or stakeholders, and software implementation should seek to satisfy these requirements as faithfully as possible. These are the requirements by which the software will be judged for correctness and completeness.
Change Management
Software changes are typically tracked in source control. The source control system provides a historical progression of the software as it evolves over time. Each of these software changes can represent a new feature which satisfies a product requirement, a bug fix which corrects undesirable behavior, or other improvements or alterations to the source code. Establishing links between each change and the corresponding requirement or defect that initiated the change allows for traceability forward or backward through the development lifecycle. Enforcing these links is a critical role of commit hooks within the change management system.
Build and Release Management
The build and release process is responsible for translating the software source code into an executable or installable piece of software. It often includes compiling the source code, identifying external software dependencies, and packaging the software into a format that can be distributed and installed by the software consumer. One of the key objectives of build and release management is to produce a complete record of what went into the production of the software product. This record helps to establish the link between what the developers produced and the software received by the customer. Ideally it should be possible to use this record to identify the precise contents of the software product and to reliably reproduce the software in order to perform updates or debug issues.
Defect Management
By its nature, software is inherently complex and therefore flawed. Developers may misinterpret requirements, make logical mistakes, or simply fail to account for all possible outcomes. Identifying and tracking software defects is a critical part of the software development process. The defect tracking system can often serve as a barometer for the product quality or the amount of effort required to resolve any known issues. It is also a link to gaps in the product requirements or errors in the software code. The defects help identify what errors have been found, which product versions they have been found in, and the product versions where they may or may not have been fixed.
Test Case Management
A test case is a definition of what tests need to be conducted against a specific product version. The test case management system is an invaluable tool for testing organizations to determine how much work is required to validate the quality of a software product. It provides a record of test execution and outcome for each release of a software product. Establishing links between the test cases, released artifacts, and product defects provides insight into the effectiveness of product testing and the amount of test coverage achieved for each product release.
Integrated Solutions
Although it is quite common for organizations to select a variety of different vendors or open source applications for their software development pipeline, there are many commercial vendors who provide a suite of integrated applications which cover many aspects of the development lifecycle. Although few of these vendors provide full coverage of the application lifecycle, some cover a significant portion of it. Popular vendors in this area include Atlassian, JetBrains, GitHub, and GitLab.
Atlassian
Most commonly known for their Jira defect tracking software, Atlassian has acquired several other software development applications and integrated them into their product portfolio. Jira’s plugin architecture allows it to fill multiple roles such as defect tracking, requirements tracking, and test case management. As with many applications, its strength continues to be the defect tracking functionality on which it was founded.
JetBrains
JetBrains gained popularity with its widely used IntelliJ development editor, which continues to be its strength. However, they also offer YouTrack, a defect tracking and project management software. Their TeamCity application is a very comprehensive alternative to Jenkins, and Upsource provides code review functionality on top of a variety of source control systems.
GitLab and GitHub
Although most people think of GitLab and GitHub as a source control application, they offer a comprehensive set of features to cover a breadth of the software development lifecycle. Rather than creating or acquiring a collection of loosely coupled applications, both have created a fully integrated set of features that includes code review, wiki, continuous integration, defect tracking, etc.
Choosing Wisely
With so many options to choose from, how can an organization make the best choice for long terms success? First and foremost, approach the product selection process with a comprehensive strategy. Allowing developers to select the source control system, testers to select the test management system, and project managers to select the requirements tracking system just leads to a hodge-podge of poorly integrated applications that cost far more than necessary. In modern software development, cross-functional teams need to work closely together and the supporting applications should do the same. Establishing a small, cross-functional team of process champions to participate in the selection and evaluation process can often be the best approach for selecting a good fit for your organization.
Establish Priorities
Make sure that a clear set of priorities have been defined to help narrow the options. If strong cross-team collaboration is a high priority, then a highly integrated application may be the best choice. If your organization is highly developer-centric, then products with strong IDE or tool integration may be best. It is important to understand where users will spend a significant amount of their time in order to select a product that will feel the most natural.
User Preference
Have users evaluate the application in the context of the entire software development process. Is there a natural flow or progression from requirements gathering to implementation to release? Can users from various teams intuitively understand the interface and how to navigate through a project? If the users get lost trying to navigate through the application, it probably has usability issues that will lead to frustration and resentment during initial adoption.
Application Cost
The following diagram illustrates the approximate annual licensing cost per engineer, assuming a department of 500 engineers. Keep in mind this only represents application licensing costs. Even though the open source projects are “free” to use, it takes an operations staff to run an internally deployed environment. So if you save $100k on licensing costs, but need to hire two full time engineers to support the environment, then operational support needs to be factored in to the budget.
There are a huge number of variables that need to be accounted for when estimating the cost of adopting a new application:
- Can it be hosted externally (SaaS)? Usually hosted solutions are more cost effective because it reduces the in-house operational costs and expertise required to run the application.
- How many users will each application need to support? As the number of users increases, the operational support load increases because it takes more effort to scale and run the application.
- What is the budget approval process like? If finance or executives do not recognize the value of purchasing commercial software, you may find yourself fighting for renewal budget every year.
Size and Scale
SDLC applications tend to scale fairly well below 500 licensed users (~100 concurrent users), but the operational complexity increases steadily as the number of users increase. Developers can often deploy and manage the applications themselves in a small environment, but once there are thousands of users, it can be a full time job keeping the applications running. The additional complexity of regular maintenance and upgrades, especially if the development organization is globally distributed and has need for a highly available environment, can be costly. If these applications are hosted in-house and have a large number of users, plan for an operations staff that can support a larger environment.
Integration with Other Applications
A key element of any software development application is the ability to integrate with other applications. This is especially true for SDLC applications which rely on integration to establish links between requirements, implementation, and testing. Most modern web applications support web hooks (outbound) or REST APIs (inbound) as a means to integrate with other applications. If the application supports customizations or plugins, there will often be third-party plugins that provide the pre-defined integration logic. Some examples of this include:
- Jenkins plugins — there are a huge variety of Jenkins plugins to perform all manner of tasks. This allows Jenkins to integrate with almost any application that provides an external API. An example of this would be the TestRail plugin which submits test results produced by a Jenkins job to the TestRail application.
- Jira plugins — Atlassian hosts a large marketplace of Jira plugins that extend the functionality of Jira. In addition to plugins, it is quite common for the source control system to implement hooks which invoke the Jira REST API to update stories when commit messages contain a reference to the story ID.
- Artifactory plugins — Artifactory makes it quite easy to drop Groovy scripts into a deployment directory in order to hook into the application event model. It also provides an extensive REST API for interacting with the application.
Next Steps
This article should give the casual reader a foundation for understanding the various applications that can be used to facilitate the software development process. Within a few weeks, I’ll publish a follow-up article to give a similar overview of the operational applications that are used to support a suite of SDLC applications. I currently have an outline for 10 articles that center around the common theme of Release Engineering Operations. This is my first blog post so feel free to contact me or clap/comment to let me know whether the information was useful.
