patpitchaya - Fotolia
Decades ago, an expert said, "The wonderful thing about standards is that there are so many of them to choose from." That same thing could be said about software development and software lifecycle integration. Things like Agile development and continuous delivery have created tension between the goals of making software development teams optimally productive and making development practices consistent and manageable.
To resolve the tension, select an SLI model that fits your development and deployment practices, manage the connections between classic software lifecycle tools and look to future enhancements in development and deployment to further support SLI goals.
Most software professionals recognize that the problem of software lifecycle integration arises because the tools used for responsive development and those used for efficient development are themselves different. Development tools, application lifecycle management (ALM) tools and deployment tools all focus on their own specific piece of the problem, and SLI is supposed to tie them together. The big question software development teams face is whether to achieve SLI through automation (tools) or through practices, and the best answer will likely depend on how your company uses software and where it is with regard to Agile development and continuous delivery.
Development-centric vs. modernization-centric
Companies that make continuous changes to components of what is a generally stable software deployment model are development-centric. Here, the focus has to be making software development teams as productive as possible and certifying new versions of existing components. Companies that are changing/modernizing their IT models are modernization-centric, and those that are transforming infrastructure, including adopting public cloud services, are deployment-centric. The ideal SLI strategy for each of these approaches is different.
For development- or modernization-centric organizations, there are two possible SLI options. The first is to adopt a formal tool-based integration strategy, and the second is to rely on practices to create specific integration points where diverse tools can be harmonized. The former is clearly easier; the development processes haven't generated a lot of divergent tools and practices, so the first approach is most likely to fit newly launched app mod projects, as well as firms just committing to Agile development. For the rest, it may be easier to rely more on practices.
The best way to start a tool-driven SLI project is with ALM tools, from which you can evolve both in the direction of development -- via an integrated development environment (IDE) -- and deployment -- via DevOps. The use of any IDE that's strongly coupled to ALM, including the offerings of Dell, Hewlett Packard Enterprise, IBM, Microsoft, Oracle (for Java) and Red Hat, will considerably simplify an integration-middleware approach to SLI. Most organizations will have suitable ALM and IDE tools in place, with integration between them.
If you don't have an ALM focus yet, consider Eclipse Mylyn, which is the ALM tool for Eclipse, an open source IDE. Because many organizations use Eclipse as an IDE (and nearly all could adopt it easily), a Mylyn-centric evolution to SLI will naturally embrace development as well, giving you two of the three key pieces of SLI.
Development-centric companies still have to deploy, and companies who are deployment-centric (including those relying exclusively on third-party software) will focus there alone. DevOps integration is thus a pervasive issue. If you already use DevOps and develop software in-house, you likely have framed development-to-deployment integration in terms of your current tools in both areas. Deployment-centric companies who are involved in public cloud deployment may also have a DevOps strategy, based on cloud provider tools.
Tool-based SLI will rely on the interfaces available in the IDE, ALM tools and DevOps tools to transfer signals of progress or issues to another part of the lifecycle. The availability of these signaling interfaces is expanding as interest in lifecycle integration grows, so take time to review your own tools and their options before you start.
The practice-based approach to SLI generally focuses on three specific integration points: unit/component release (IDE), application release (ALM) and deployment (DevOps). All of the tools used in the phases these three points connect are tuned to create as unified a result as possible at the integration points, and development/operations personnel are then tasked with ensuring that the appropriate steps are initiated at each point, regardless of the tools and practices that moved the process there. Practice-driven SLI can rely on project management tools to couple the IDE/ALM/DevOps elements by organizing how they're used.
Both these techniques require that there be codified integration steps -- in one case, to build specific message steering rules and, in the other, to guide manual or assisted-manual practices. Remember that the tools to be integrated will include IDE, ALM and DevOps and that the framework in which they are connected forms the flow of your SLI process. Generally, the goal is to ensure two things: an event (like a software module being updated) can signal the initiation of the next step in the SLI process and the information needed for that next step is available from the event.
Many organizations are finding that even linking their IDE, ALM and DevOps tools in a basic way won't address the needs of continuous development and deployment. For those, you'll need to unite all your tools in a common software framework, something that could be considered SLI middleware. The integration-middleware approach to SLI has been pioneered by Tasktop, which recommends a bus approach, not unlike that of the enterprise service bus. In the integration-middleware model, each of the elements of development and deployment are interfaced to a common message exchange point, so each can send work to the others. Business process rules related to SLI practices are enforced by the message exchange or bus.
The pressure of continuous development and delivery is likely to morph many ALM toolkits into SLI tools, particularly as cloud development and deployment drive DevOps adoption. Watch your vendors' progress here, and be prepared to make changes in your tools as your needs and product capabilities improve.
DevOps puts onus on software developers
Reworking costs in Agile, DevOps
A look at Agile impact on the enterprise