If you've taken a look at the SDLC or the DevOps Inifinity diagram, you might have noticed something missing.
Join the DZone community and get the full member experience.Join For Free
Why is software developed? There are many answers to that question. Just about any way you look at it, software is developed to serve a purpose. It might be an aid in business productivity, perform repetitive tasks, automate complex processes, for entertainment, or even improve the productivity of those writing software. Software may be written by engineers within an organization in support of the organization’s business objectives. Software is also written by vendors to be either sold as a product or offered as a service. It’s apparent that the reasons and purposes for developing software are vast.
No matter what the application, technology or team structure, developing software is often a very rewarding mix of business and technical acumen along with a strong penchant for creativity. The best efforts are supported by passionate individuals who believe in a vision and strive to produce the best possible solution. When a milestone is reached, and especially when an application is finished, entire teams feel a great deal of pride. The world of software development can be, and should be, exciting, fulfilling and fun.
You may also enjoy: Continuous Deployment: How To Stay Ahead of The Game
With few exceptions, software development teams are confronted with the real-world demands of delivering some type of application. The demands for delivery vary. There may be commitments made to customers. Regulatory compliance continues to play a greater role in impacting many projects. Investors could be looking to realize the return on investment. There’s always the more tactical demand in providing bug fixes, technology upgrades, etc. Regardless of whether a team is running Agile, Waterfall, or Ah-Hoc, the iron triangle of project management rules.
There isn’t a development project that doesn’t wrestle with the iron triangle.
There isn’t a development project that doesn’t wrestle with the iron triangle. Any two of the factors on the outside points of the triangle impacts the third. Various software development processes address the iron triangle’s challenges, but none can escape its reality. Over the years, the placement of Quality in the diagram has varied. Today, most depictions of the iron triangle have Quality at the center of any effort. Attempts at circumventing the reality of the iron triangle almost always has a direct impact on quality.
Where does this lead? There are features to build, demands to meet, processes to follow, quality to maintain, and so on. None of these have true meaning unless the software is deployed. This is a given. Everyone on a development team knows this. The stakeholders in a business know this. Deploying an application is the point at which everyone’s hard work is officially revealed. Customers, investors, executives and others are excited by a new software release. The development teams will often have some type of celebration. Scope creep and inaccurate estimates aside, deploying software is a great accomplishment.
When is Done Really Done?
However, a glance at the iron triangle mentions nothing about this critical factor in the release cycle: the actual deployment. Everyone involved in the development of software implicitly understands that the resultant deliverable will have to be deployed. Perhaps it’s considered a non-functional requirement. In its list of example non-functional requirements, Wikipedia includes Deployment. In a review of the Wikipedia article on non-functional requirements, many of the examples listed depend on the deployment of an application to have occurred in order to be evaluated. If non-functional requirements are to be prioritized, it’s quite likely that deployment will be toward the top of the list; if not at the very top of the list.
Why shift the focus of this discussion from developing software to deployment? It’s the gray area in the Software Development Life Cycle (SDLC). The word deployment is defined in the Oxford dictionary as “The action of bringing resources into effective action.” A quick look at this definition seems to imply the work required to take the means by which something can be accomplished to a state enabling it to meet its objective. It’s a reasonable definition of deployment. Taking the means by which something can be accomplished, such as an application, and enabling it to meet its objective; for example, making the application available to users. It can be derived that there’s a process required for deployment to occur.
No matter how software is deployed, it often involves individuals or teams that typically do not take part in developing the software. This is contrary to roles such as quality assurance where development and quality assurance team members work closely with one another. In fact, Agile processes dictate a close relationship between quality assurance and developers. This has not been the case for those responsible for deploying the software. In Agile-speak, those responsible for deploying the software are often cast in the role of chicken – those who consult on the effort and are informed of its progress.
The Missing Link
Whether it’s been a smooth or rocky release cycle, eventually, an application is deemed worthy of release. Now it’s time to reap the benefits of everyone’s hard work. It’s time to deploy the software. As previously stated, everyone on the project knows the goal is to deploy the application. It may be even documented as a non-functional requirement, but how much attention was truly paid to the deployment process? Throughout development, without a conscious effort given to deployment, teams find themselves realizing that, in fact, the release is not complete, because the deployment process has not been thoroughly worked out and tested. What often ensues is a tense, high-pressure effort to truly finish the application by working through the deployment process.
It’s not that during development that the application is never deployed. At the very least, most teams will do some type of deployment for integration testing or quality assurance work. Many teams will also do some work to validate that the application executes in the production runtime environment. However, a rock-solid, documented and automated deployment process always seems to be a job done during development as fill-in work or by a separate team altogether toward the end of a release cycle. Deployment tends to fall into to the gray areas of, “We’ll get to it,” or “The XYZ team has it under control.” When it comes time to deploy, the missing link becomes obvious, and the finger-pointing begins.
Discussions, such as the one being undertaken here, will paint similar pictures to the one described above and jump into a conversation on how DevOps will save the day. The problem is, like many concepts in the IT world, that an idea, practice, pattern, etc., take on a life of their own. There’s a debate. There’s a specific application. There are distortions. What starts out as a simple concept ends up with layer upon layer of sometimes relevant, but often impractical or complex constructs.
At its core, DevOps is simply a set of best practices applied to a team’s SDLC to ensure consistency in application releases with a high degree of quality. For several years now, the DevOps topic has been so hot, that many, many articles, blogs, books, seminars, and so on exist. The remainder of this discussion is not going to pile on to these resources, many of which are very good. Rather, using what has become a common depiction of DevOps, the DevOps Infinity Diagram, the discussion will conclude with process, team and architectural considerations as it relates to application deployment.
Organizations differ in maturity, size, and objectives, so there is no one-size-fits-all DevOps formula. However, there are key principles and patterns that apply. Often, when reviewing the DevOps Infinity Diagram, tools are discussed. The principles and patterns outlined below do not discuss tools. Tool selection is a cross-section of technology stacks, deployment topologies, cost, etc. Tools should also meet the needs an organization’s deployment strategy. Tools are the means by which the DevOps process efficiently executes. Without a reasonable idea on how an organization will establish its DevOps process, a discussion of tools is premature.
Reviewing the Elements of the DevOps Infinity Diagram
Books have been written on this topic. Discussion of the DevOps Infinity Diagram is a broad topic. For the purpose of this discussion, the focus will be on deployment process. In and of itself, deployment process is a large topic. Here, only high-level thoughts are presented. Since this discussion has remained technology agnostic, examining the diagram’s elements will look at the mindset and considerations.
Where’s the team called out in the diagram? Technically, it isn’t. It’s implied. DevOps only succeeds when everyone is on board and everyone has a say in how the process is defined. Usually, the challenge is in bringing multiple departments and/or disciplines together. For example, if an organization has an operations team that is responsible for maintaining a production environment, at the very outset of a project, members of the operations team need to have a seat at the table. As this is a cross-discipline team, it’s important to create and environment where no one discipline is dictating. This is not easy, but it is absolutely essential.
When it comes right down to it, each of the elements describe typical SDLC process steps. Oddly enough, this very first element of planning is where projects can immediately go off the rails. Product and development teams have multiple processes to choose from, all of which call out some type of planning stage. The objective of the plan is to define how the release cycle is executed. It’s at this first step where the initial cross-discipline team discussion needs to begin. Not everything needs to be known, but by starting the dialog early, surprises, such as a last-minute need for a new technology in the production environment, should be minimal.
Here’s where a release’s planned functionality is developed. Coding and testing are done within the organization’s process and tools. It’s not all about application functionality though. How much deployment work is being done here? Deployment code should be developed in lockstep with application functionality. Like any other code, the sooner the deployment code is written, the more time to validate its functionality. Consideration also needs to be made for the application to provide data on performance metrics and diagnostic logging. These are critical to the monitoring element.
Quality throughout the process is essential. As might be surmised in the descriptions of the previous elements, application verification is not just about validating application functionality. Time must be allocated to validate application deployment, and in the case of updates, updating an existing application deployment. Verification will typically include various performance and resilience testing. Here, application provided metrics and diagnostic logs can be reviewed to ensure good information is being provided that will aid in monitoring an application in production.
Packaging an application affects multiple elements. The process by which an application is to be deployed into production should be followed in the development process. Executing and testing an application from an IDE is fine, but the real testing begins when an application is retrieved from whatever distribution mechanism is used for production applications. The verify element of the process should only be executed off the same packaging process as production; even for snapshot or development releases.
The key test [for deployment] is that a business sponsor could request that the current development version of the software can be deployed into production at a moment's notice - and nobody would bat an eyelid, let alone panic. - Martin Fowler
The goal here is plainly stated by Martin Fowler, “The key test [for deployment] is that a business sponsor could request that the current development version of the software can be deployed into production at a moment's notice - and nobody would bat an eyelid, let alone panic.” With the previous elements iterating through deployment work; just as application functionality, a release into production should be a non-event. Due to compliance or auditing requirements, some organizations will require a manual step for deployment. For others, the process of deployment into production could be completely automated.
The release and configure elements are closely related, though calling them out separately is important. It’s likely that throughout deployment testing, especially during the development cycles that environments used in deployment testing are not equal in size to a full production environment. They’ll be more “production-like.” Building into an application parameters and configuration directives that allow an application to be deployed in various environments aids in streamlining the deployment process and provides consistency across all deployment environments. Deployment into production simply becomes a matter of using the same deployment process used during the development process with parameters set that are specific to the production environment. Since the goal of a release is to be a non-event, configuring a release follows suit.
While in production, those responsible for maintaining the application will rely on the metrics and diagnostics information built into an application. Even though performance testing will have been done during application verification, there are always new revelations in production. Monitoring is as much used to ensure an application is running properly as it is in providing application improvement feedback.
The process comes full circle. Data, observations, insights, etc. become a part of the continuous loop. This cross-discipline effort looks to improve the application throughout every stage in the process. Information gathered in the previous iteration through the cycle is fed into the next iteration to serve as a mechanism for continuous improvement.
Deployment needs to begin with the first line of code.
Deployment Does Matter
While deployment is known to be a fact in application development, it’s often considered an add-on rather than an integral part of the release cycle. Deployment needs to begin with the first line of code. Tooling, process, team makeup are key facets to DevOps. However, keeping the end goal of efficient, uneventful release cycles must remain the primary objective. Efficiencies in the release cycle assist in keeping costs in check. For many organizations, the ability to rapidly deploy versions of applications can be used as a competitive advantage. No matter an organization’s SDLC, an effective DevOps component delivers tangible results.
Opinions expressed by DZone contributors are their own.