devopsy.kinsta.cloud

Tag: continuous delivery

  • How Often Should You Release with Continuous Delivery?

    How Often Should You Release with Continuous Delivery?

    If you do continuous delivery, you could release software updates as frequently as you want. But should you? Here’s what to consider when deciding how often to release.

    Although the terms continuous delivery and continuous deployment are often used interchangeably, they don’t mean the same thing. Under continuous delivery, you prepare all software updates as potential candidates for release. But continuous delivery on its own does not mean that you release all of those updates into production as soon as they are complete. You would have to adopt continuous deployment to do that.

    So, if you’re doing continuous delivery, you have the option of releasing as frequently as you like—every day, every month or even every hour. Determining how often you actually release requires weighing several important factors, including:

    • How important are your updates? If changes to your app mostly involve mundane things such as interface tweaks, continuous deployment probably will confuse users more than please them. They will have to adapt constantly to new features. But if you can roll out big, user-friendly changes on a continual basis, then deploying continuously can help keep your users happy.
    • Is there a marketing advantage to be gained by waiting longer to release? Sometimes, advertising new features but waiting a while to release them can help build excitement. Case in point: Apple Inc.
    • Do other apps depend on your app? If you’re working within an ecosystem where your app integrates with other apps or platforms, continuous deployment makes the lives of partner developers more difficult because it requires them to adjust constantly to changes in your app. To help them ensure their work will always be compatible with yours, provide space between your releases.
    • Is your development pace consistent? If not, continuous deployment can be problematic because users will see rapid updates at some times, but stagnation at other times. Continuous deployment only works well for users if they can count on a relatively steady stream of updates.
    • Do your updates create a learning curve? If users will have to learn new tricks to use an updated app, continuous deployment may create more confusion than happiness.
    • Can multiple versions of your app coexist? If all users need to be running the same version of your app in order to be current, continuous deployment can help assure that they are. But if you can support multiple versions of the same app at once, less frequent releases should work for you.

    If you can’t decide how frequently to release, you might consider releasing on a fixed time schedule—once every two months, every six months, every year or whatever works for you. This is what Canonical has done with Ubuntu Linux for a long time: It releases a new version of the operating system on the second Thursday of October and the fourth Thursday of April each year (with a few exceptions). This system assures that developers and users always know the schedule for a new release.

    Whatever approach you take, the most important thing is to realize that continuous delivery does not require you to release as often as you can. It gives you the flexibility to release as often as you want. Deciding how often that should be is up to you.

    — Chris Tozzi

  • Assembling the Key Components of Continuous Delivery

    Assembling the Key Components of Continuous Delivery

    As agile methodology was popularized at the start of last decade, engineering teams gained the opportunity to begin producing software in shorter cycles, while releasing it reliably at more frequent intervals.

    This concept garnered greater attention in 2009, when Tim Fitz published his thoughts on continuous deployment. By the time Jez Humble authored his seminal book, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation,” in 2010, the approach started to get significant mindshare. In the book, Humble advanced the three building blocks of continuous delivery: configuration management, continuous integration and continuous testing.

    Thereafter, Agile Operations—the practice of using end-to-end monitoring, fueled by analytics, to increase operational agility—appeared. This complemented continuous delivery, with the goal of increasing the quality and velocity of software delivery while minimizing overhead.

    Since then, and particularly over the last six years as DevOps adoption has exploded, there’s been significant discussion (and confusion) over the opportunity to embrace “continuous everything” across the software development life cycle (SDLC) to deliver functionality continuously and optimize end-user experience.

    Today, having spoken to hundreds of organizations employing agile and DevOps, it’s possible to expand on these concepts to better define the key components of continuous delivery.

    In this blog, I’ll detail the precepts of “CD” that CA’s customers recognize as critical in reducing the time, risk and expense of software delivery by frequently releasing smaller batches of code with extensive visibility and traceability.

    These building blocks of continuous delivery are:

    • Continuous development & integration,
    • Continuous testing. and
    • Continuous release.

    Continuous Development and Integration

    When it comes to delivering quality apps faster, every second counts.

    That’s why it’s important to automate the planning, development, unit testing and integration of code with different inter-dependent components, all while packaging it for quality assurance. We categorize these activities under continuous development and integration, as shown in Fig 1.

    This all starts with sprint planning and modeling of requirements in agile management software. Unit tests can be created automatically, based on requirements and use case stories. These unit tests then can be executed automatically based on pre-defined criterion, using automatically generated synthetic data.

    Fig 1: Continuous Development and Integration

    Next, virtual service interfaces can be generated automatically by simulating unavailable systems across the SDLC, allowing developers, testers, integration and performance monitoring teams to work in parallel—driving faster delivery, along with higher quality and reliability.

    The integrated code can be built and tested automatically against validation criterion, and upon passing, made available for continuous testing. This later phase, after code development and before QA, is also commonly referred to as continuous integration.

    Continuous Testing

    Continuous testing across app delivery not only enables enterprises to shift testing left, engaging it earlier in the SDLC, but it also helps them shift right, leveraging the same processes throughout staging and production.

    After the unit tests are passed and integrated builds are made available for QA, functional and performance tests can be completed—before the build is made available for staging and production. Various activities during continuous testing are shown in Fig 2.

    Before the functional and performance tests are performed, the build promotion criterion and configuration also need to be validated. Testers require provisioning of QA environments to deploy the build, along with virtual services and test data. Using test data management to create a subset of production data and mask sensitive information is another continuous testing requirement.

    Fig 2: Continuous Testing

    It’s also important to engage application performance monitoring in the QA environment before running automated tests, providing feedback about any problems back to developers.

    After the automated tests are executed and promotion criterion are met, the build is ready for deployment in staging or production environments.

    Continuous Release

    Continuous release matches release velocity to development velocity through controlled and scalable deployments.

    The goal of continuous release (sometimes referred to as continuous deployment) is to continually and automatically deploy the build into production; similar activities also can be performed in a staging environment.

    As shown in Fig 3, build configuration needs to be validated, with the production environment configuration updated before being sent to production. As with application code, configuration is also maintained in the version control system and can be automated for deployment.

    Fig 3: Continuous Release

    After the build is deployed into production, application monitoring should be initiated to track performance and customer experience. Feedback from the production environment can be passed back to developers to guide enhancements or sprint backlogs.

    This blog aims to outline core CD activities, and in subsequent articles I’ll provide additional details on entry and exit criterion, as well as metrics useful in tracking continuous development & integration, continuous testing and continuous release.

    In the meantime, check out, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory,” a new book authored by my colleagues Aruna Ravichandran, Kieran Taylor and Pete Waterhouse.

    Based on learnings gained from numerous customers who have already embraced CD and DevOps, it highlights key practices for starting this journey, related ROI metrics and other useful tips.

    — Anand Akela

  • Should Continuous Deployment Be Renamed?

    Should Continuous Deployment Be Renamed?

    I’m a technologist turned into a word person. For those of you who know me, I started as a developer, learned ops and security as it was needed, and eventually my love of talking about technology lead me to writing, tech marketing and evangelism. I still develop, though; I can’t stop that—it’s kind of a part of me.

    But as a technologist at heart, words are a way to convey concepts, and any that don’t contribute to the conversation in a meaningful way aren’t necessary.

    So it is pretty weird for me to be saying, “What if we renamed CD?” But I think there is a real point here that we could address. If you look across the industry, you will find quotes (and in IT departments, the reality) that for most of us, CD is not about continuous deployment. It is about continuous delivery and on-demand deployment. Unfortunately, “on-demand deployment” makes a pretty terrible acronym in the English-speaking world, so perhaps we should use “on-demand update.” Deployment is looking at it from the application’s perspective, but as DevOps, we get to look at it from both perspectives and we are updating the server(s) to run our application(s). So on-demand update (ODU) would work, but I’d be open to alternatives.

    In this case, the wording change is useful. There are a few organizations with very special needs that do actual continuous deployment. No one else does. The ability to say, “OK, we’ve got enough together and tested to warrant the disruption this will cause. Update the app,” is what most organizations use CD for. And I think that’s right. While purists will roll their eyes and talk about the advantages of each bug fix, no matter how small, rolling out in a timely manner, most orgs aren’t going to do 15 updates a day. And orgs that like stability don’t want to. Testing doesn’t resolve every issue; otherwise, we wouldn’t need things like Bugzilla for anything in production, risking introduction of new ones 15 times a day. That’s just not on the list of priorities for most organizations, particularly if their CI system is on longer run-times.

    So I like CI/CD/ODU. Then you are separating continuous delivery and on-demand deployment, which I would argue is a huge piece of the problem. I’ll quote Georg von Sperling of CA Technologies during the Q&A section of a webinar:

    Continuous delivery does not equate continuous deployment to production. If I may be so bold, I would state continuous delivery is a practice to allow deployment to production at any time with a high degree of quality and a low amount of risk with zero downtime and zero touch. A business leader recently said to me that whereas, in the past, ‘Deployment to production was an IT decision, it is now a business decision at a push of a button.’ But, CD certainly played a part in this paradigm shift, as the entire delivery process, including testing, is visible and predictable.

    Which makes sense, once explained, but it’s truly a source of confusion in the field, so separating the two makes sense. The point is to communicate clearly, and requiring a further clarification of what exactly CD is says we’re not communicating clearly at all. Indeed, delivery and deployment definitions that are meaningful to IT are close enough in context as to automatically cause the confusion when a single “CD” is presented.

    So even though I don’t get terribly wrapped up in wording, I think this is a worthwhile change to consider. Words convey meaning; let’s ensure the meaning they convey is clear.

    For those of you knee-deep in CI/CD, yes I am aware of Fowler’s definitions, but this clears up the fact that he has to explain how continuous delivery is different from continuous deployment in the definition for continuous delivery.

    In short, we’re being confusing. Stop it. Let’s talk about tools/technologies/methodologies to get there, not keep clarifying confusing terminology.

    — Don Macvittie

  • When Technology Doesn’t Matter

    When Technology Doesn’t Matter

    Over 10 years ago, Nick Carr wrote an article in the Harvard Business Review with the title, “IT Doesn’t Matter.” As you might expect, an article with a title like that generated a significant amount of controversy. CEOs from leading technology companies and other writers at the time panned Carr’s premise in a way that, in retrospect, seems a bit overly defensive.

    His point, after all, was not that IT was not unimportant; rather, IT (as vaguely defined in the article) was so ubiquitous that it was no longer a competitive advantage. Rather, it was what companies did with their IT technologies that provided competitive advantage. It’s also worth noting that his (seemingly) intentionally vague definition appeared to focus on the generic notion of IT as PCs, servers and things that had become commonplace at the time.

    This has been a common pattern throughout the history of technology: Early adopters enjoy a competitive advantage, but only as long as the technology they’ve adopted remains scarcely used. Any advantage goes away when the technology becomes ubiquitous. The technology remains important—even critical—to a business’ operations, but it’s hardly an advantage when everyone else has the similar technology.

    Carr’s article uses the example of electricity: In the late 19th century, when electricity was an emerging and scarce technology, factories that were able to leverage electricity for their manufacturing efforts held a significant advantage. Today, no factory can operate without electricity, yet it’s hardly considered a strategic asset.

    Today in the 21st century, we’re seeing a similar trend repeated, but on much compressed time scale. Providing free Wi-Fi was once a lure for customers of restaurants, coffee shops and the like, but today it’s essentially table stakes. Likewise, leveraging clouds was once a competitive advantage, but with more than 90 percent of companies using some form of public or private clouds, one would be hard-pressed to argue that cloud usage alone provides any significant advantage. However, how you use these clouds can, in fact, become a competitive advantage. CA offers a variety of tools to help you manage, secure and accelerate your use of clouds.

    It’s an important lesson to learn: In the application economy, early adopters enjoy an important—yet relatively short-lived— competitive advantage. Knowing when to jump on an emerging technology can be the difference between surviving and thriving.

    Today, there are several technologies that are on the cusp and moving quickly to adopt them can provide a significant competitive advantage. The ability to deliver software continuously—while not exactly a single technology—is on this cusp. Continuous delivery is a core component of a successful DevOps implementation, and means essentially what it sounds like: the ability to deliver software from planning to production in a near constant and continuous fashion. Achieving true continuous delivery means you must test continuously, develop continuously and release continuously.

    Continuous delivery is not easy to achieve, but for those who do the advantage is significant. Companies implementing continuous delivery can get to market 20x faster with 98 percent fewer production errors. That’s a powerful benefit.

    To learn more about CA’s portfolio of continuous delivery solutions—and hear directly from several customers—you can check out the replay of Jeff Scheaffer’s keynote presentation from CAWorld 2016.

    — Brendan Hayes

  • Welcome to the CD Neighborhood

    Welcome to the CD Neighborhood

    Today we opened a new neighborhood or section here on devopsy.kinsta.cloud. It is called the CD neighborhood and it will feature content on CD and related content. The neighborhood is sponsored by CA Technologies, who will also contribute content to the new neighborhood.

    CA authored content will be clearly marked. CA employees have contributed by lined articles to devopsy.kinsta.cloud for a long time and they have some great DevOps thought leaders. Recently they have also acquired Blazemeter and just announced the intent to acquire Automic as well. This should mean even more great content from them.

    But CA is not the only content provider for the new CD neighborhood. The devopsy.kinsta.cloud staff writers will be contributing to the neighborhood on a regular basis. In addition, contributed articles that are on theme will also be posted here on a near daily basis. In fact I encourage you to submit your thoughts on CD to me at editor@devops.com, if you have something to say on the subject.

    In addition to written articles, the CD neighborhood will also host both audio and video content that is on point. Many will come from our DevOpsTV YouTube channel and DevOps Chats hosted on SoundCloud.

    With CD being such an important part of DevOps we think that the CD neighborhood is going to be a favorite destination for many of you. We will do our best to keep it fresh, informative and useful!

    — Alan Shimel

  • Adding Usability Testing to the CD Pipeline

    Adding Usability Testing to the CD Pipeline

    Do you include usability tests in your continuous delivery pipeline? If not, you could be making a big mistake.

    Usability testing, which entails having actual users test an application for user-friendliness, intuitiveness and accessibility, gets easily lost within the DevOps conversation. If you want to do continuous delivery, waiting on manual usability tests may seem like a major barrier.

    Why Usability Testing Matters

    Yet, DevOps teams that ignore the importance of usability tests do so at their peril. Continuously delivered apps will provide little value if they are difficult for ordinary people to use. Users have little tolerance for applications that lack usability.

    It’s worth noting, too, that DevOps makes usability testing even more important than it would be within a waterfall delivery chain. When you do continuous delivery, your software changes more quickly. That increases the chances of introducing a change into production that negatively impacts app usability.

    How to Do DevOps Usability Tests

    So, how can you do proper usability testing without slowing down your continuous delivery pipeline? Unfortunately, there’s no easy solution. Unlike integration and unit tests, usability tests cannot be easily automated.

    You can, however, work closely with your in-house QA team to perform usability tests before changes reach the production stage of your pipeline. This will work as long as your QA team is able to replicate real-world usability conditions well.

    Alternatively, you could release changes to a select group of users before making them generally available. Those users would then test for usability issues quickly and report them to you before your updates reach the wild. This scenario would essentially mean doing a very fast beta release for certain users. If that seems unfeasible, keep in mind that, as long as each of your continuously delivered changes is minor, quick beta testing is manageable.

    Whatever you do, the most important thing is to avoid ignoring usability testing. Otherwise, all of the hard work you put into continuously delivering your app could be for nought.

    — Chris Tozzi

  • Mainframe Apps and the Long View of DevOps Strategy

    Mainframe Apps and the Long View of DevOps Strategy

    IT is constantly under intense short-term pressures. Line of business (LOB) executives demand a competitive advantage in digital customer engagement now. Marketing leaders demand better customer analytics now. Legal demands better audit reporting now.

    In fact, much of the investment that companies are making in Agile, DevOps and continuous delivery is due to the urgent, short-term demands of the business.

    But short-term actions alone are insufficient for business success. IT leaders must also strategically navigate the vagaries of the digital economy over the long term—or, as Wayne Gretzky’s father taught him, to “skate to where the puck is going to be.” Otherwise, today’s small wins inevitably will lead to tomorrow’s egregious failures and inefficiencies.

    And integration of your mainframe apps and data into your enterprise DevOps tool chain is central to that long-term digital strategy.

    Here’s why.

    The Mainframe: Big, Nimble Iron

    A DevOps tool chain is only as fast as its slowest link. For most large enterprises, that slow link is the mainframe.

    Slow, waterfall-bound and underautomated mainframe dev/test processes are non-trivial—because mainframe applications and data are non-trivial. They typically are an organization’s most important apps and data. So if you can’t modify your mainframe application logic quickly or leverage your mainframe data in new ways easily, you’re uncompetitive toast in today’s fast-moving markets.

    Also, mainframe applications and data typically serve as the back-end systems of record for front-end mobile and web-based systems of engagement. Your ability to innovate and remain competitive when it comes to digital engagement and digital perceived value is, therefore, almost universally contingent on lessons learned from frequent and timely mainframe code drops.

    In other words, everything IT is under pressure to deliver—new mobile apps, better analytics, fulfillment of increasingly stringent compliance mandates, etc.—depends on bringing Agile, DevOps and (ultimately) continuous delivery to the mainframe.

    Just about everyone realizes this. Sure, there are some holdouts who still advocate something they call “bimodal IT”—which prescribes allowing the mainframe to languish in obsolete waterfall and dev/test practices while the rest of the enterprise moves forward. But bimodal lT has proven to be a mistake. An Oct. 31, 2016, Forrester Research report titled, “Predictions 2017: CIOs Push For Speed Amid Volatility,” shines a light on the fatal realities of bimodal IT:

    “In early 2016, many CIOs fell for the false promise of a bimodal strategy. They only pushed part of their team to adopt an accelerated pace — and left others unchanged. But those CIOs are already experiencing the shortcomings of operating at two speeds. Business peer frustration, polarizing and deteriorating cultures, and unsustainable operational complexities will continue, ultimately spurring most of these CIOs to course correct in 2017.”

    Given the explosion of mainframe-related innovation that has taken place in the past couple of years, enterprise IT leaders and industry analysts agree that “mainstreaming” it into enterprise DevOps is the right and necessary strategy (see as examples here and here).

    Some Good Things Take Time

    While instant gratification may be the order of the day—and gain without pain may be an all-too-frequent vendor promise—the reality is that great IT achievements all require effort, investment and time.

    Inclusion of the mainframe into your cross-platform DevOps tool chain is no exception. No CIO can achieve mainframe agility and cross-platform DevOps orchestration by simply waving a magic wand. But there is a clear, practical path to these goals for those with the requisite foresight and leadership.

    That path includes:

    • Modernizing the developer workspace. Most mainframe development is still performed in “green screen” TSO/ISPF environments that require specialized knowledge and limit staff productivity. A modernized, graphical workspace as part of a preferred DevOps tool chain will allow staff at all experience levels to perform dev/test tasks on both mainframe and non-mainframe applications.
    • Graphical visibility into existing code and data structures. Mainframe applications typically are large, complex and poorly documented. These attributes are a major impediment to mainframe transformation. The right tools enable new participants in mainframe DevOps to quickly and easily “read” existing application logic, program interdependencies and data relationships.
    • QA “shift left.” Early detection and correction of quality issues is a central principle of modern programming—and it’s particularly important on the mainframe, where there’s an especially low tolerance for error.
    • Initial Agile training and adoption. Once you put the right development environment in place, you can start shifting your process from a traditional waterfall model with large sets of requirements and long project timelines to a more incremental model that allows teams to quickly collaborate on user “stories” and “epics.”
    • Use operational data throughout the dev/test life cycle. By using operational data in the dev/test life cycle, your DevOps team can ensure that applications perform optimally in production. They also can significantly reduce your MIPS/MSU-related costs by avoiding excessive CPU consumption caused by inefficient code.
    • Agile-enable source code management (SCM) functions. Traditional mainframe SCM environments are inherently designed for waterfall development and thus are incapable of supporting Agile requirements such as parallel development on user stories. The shift to Agile-enabled SCM is, therefore, absolutely essential for mainframe transformation.
    • Automated release management. To keep pace with today’s fast-moving markets, you must be able to quickly get new code into production. That means automating and coordinating deployment of all related development artifacts across all targeted environments.
    • Cross-platform DevOps. Ultimately, you need to fully de-silo your enterprise environment so the mainframe becomes “just another platform”—albeit an especially scalable, reliable, high-performing, cost-efficient and secure one—that can be modified quickly as needed to meet the relentlessly evolving needs of the business.

    ‘What’s My Motivation?’

    With as much as IT departments have on their plates, it’s easy to continue putting off mainframe DevOps integration. But, ultimately, there are only two alternatives to doing so:

    • Re-platform your mainframe applications. This alternative has proven to be a costly and extremely risky undertaking that delivers zero benefits while it consumes resources and potentially disrupts IT operations, or
    • Continue doing nothing. This alternative puts your company at further competitive disadvantage and hastens the day when you’ll experience total mainframe paralysis due to the loss by attrition of all your veteran mainframe developers, QA specialists and operations staff.

    Viewed in this context, genuine investment in the mainframe—whether you call it modernization, mainstreaming or “Millennializing”—is the only reasonable course of action. Such investment starts improving your digital competitiveness immediately, while paving the way for a future where you can make the most of all your resources and confidently transfer platform responsibilities to your next generation of IT professionals. Including the mainframe in your broader DevOps efforts (while extremely valuable) does require commitment, and there are resources available to help. Just be wary of those who may talk a good game, but whose actions don’t really convey a strong commitment to users’ best interests. Fortunately, there are truly dedicated experts who can help every step of the way, and have direct experience modernizing on platform within their own organizations.

    It’s the smart, viable long-term DevOps strategy every CIO of a mainframe-enabled enterprise needs to adopt ASAP.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • Continuous Integration vs. Delivery vs. Deployment: What’s the Difference?

    Continuous Integration vs. Delivery vs. Deployment: What’s the Difference?

    “Continuous” is one of the most popular words in the DevOps lexicon. What does it really mean, and what is the difference between continuous delivery, continuous deployment and continuous integration? Keep reading for some perspective.

    Like many technological concepts, continuous integration, continuous delivery and continuous deployment are terms that DevOps teams tend to use without defining them precisely. For that reason, it’s worth taking a closer look at what each of these terms actually means.

    Continuous Integration

    Continuous integration can really mean one of two things, depending on the context.

    In the narrower sense, continuous integration refers to the work done by a continuous integration server, such as Jenkins or Bamboo. A continuous integration server automatically tests code written by individual developers to make sure it can be merged into the main code base. By automating this process, continuous integration servers help developers to write and test small chunks of code on an ongoing basis, which minimizes the risk that a code change could cause serious problems and force developers to revert their application to an earlier state.

    In a broader sense, continuous integration means the constant integration of changes to an application at all stages of the delivery chain. This includes but is not limited to the automated integration testing and code merging performed by an integration server. In this broader definition, continuous integration can include the integration of new design concepts to the delivery pipeline, for example. It also can involve other types of software testing beyond just automated integration tests.

    Continuous Delivery

    In most definitions, continuous delivery refers to the process of delivering software updates to users on a nearly constant basis. Continuous delivery is made possible by continuous integration and other optimizations at earlier stages of the development process. But the definition of continuous delivery gets a little cloudy when you start comparing it to continuous deployment.

    Continuous Deployment

    What’s the difference between continuous delivery and continuous deployment? For some DevOps teams, nothing. People tend to use these terms interchangeably. In fact, they are usually simply abbreviated as “CD,” leaving it up to the listener to decide what the speaker is actually talking about when he hears the term during a conversation about DevOps.

    Some developers draw a distinction between continuous delivery and continuous deployment, however. For example, Mirco Hering writes that continuous delivery requires that the DevOps team manually release updates to users. In contrast, the continuous deployment pipeline is fully automated; users get updates as soon as they are written and tested, with no manual intervention by developers.

    This distinction is a good way to think about the difference between the closely related concepts of continuous delivery and continuous deployment. It’s a distinction that will become increasingly important as technologies such as Docker make it easier to automate application deployment by allowing DevOps teams to drop new container images into production.

    What Does Continuous Mean, Anyway?

    It’s worth mentioning, too, that the word “continuous” is usually something of an exaggeration when used by DevOps folks. It implies that software changes roll down the pipeline in a totally constant, never-stopping fashion.

    That is an exaggeration. Integration, delivery and deployment are almost never completely continuous. In practice, a “continuously” integrated application is likely to be rebuilt and delivered something like every 24 hours, not every single time a code change reaches the end of the pipe.

    That rhythm is still a lot faster, and closer to continuous, than the “waterfall” delivery pipelines that were common before the introduction of DevOps. But it’s still important to understand that, even with all of the automation tools available today, software development is rarely completely continuous.

    — Chris Tozzi

  • 7 Best Practices for Continuous Delivery Success

    7 Best Practices for Continuous Delivery Success

    Continuous delivery refers to the development of software in short and ongoing build-test-release cycles along the deployment pipeline. Repeated testing of processes and scripts before deployment to production means most errors are discovered early on and have minimal impact. Plus, finding and fixing such errors is much easier with fewer changes per release—software is released faster and more frequently with fewer deployment problems due to a heavy focus on visibility, instant feedback and incremental changes.

    To accomplish this, companies must have a straightforward and repeatable deployment process. Most reliable, of course, is an automated deployment pipeline that can feed into any environment.

    We have identified seven continuous delivery best practices that are supported by a set of complementary task-specific tools, in what’s known as the “DevOps toolchain,” to automate the process from end to end and minimize human error.

    Version-Control Everything

    The native code deployment process generally includes a built-in safety net, preventing out-of-process, locally generated artifacts from entering the production environment. Every change a developer makes must be documented in the source control repository or it is not included in the build process. If a developer copies an artifact generated locally to a test environment, the next deployment will override this out-of-process change.

    This insistence on having a single source of truth—and a reliable one—creates a stable foundation for all development processes. However, the processes are only as strong as their weakest link. That’s why the primary golden rule for effective continuous delivery is to version-control everything. What works well for code also will preserve the integrity of configuration, scripts, databases, website html and even documentation.

    Build Binaries Once

    Not every organization’s build process is the same or uses the same tools, but every build process in a single organization must be completely consistent. Whether the build is a single file deployed to an automated test environment or a complex build with several different possible deployment versions, each build version should happen exactly the same way and result in unique binary artifacts.

    This one-time-only compiling eliminates the risk of untracked differences due to various deployment environments, third-party libraries or different compilation contexts or configurations that will result in an unstable or unpredictable release. Save the compilation phase output (the binaries) to a binary repository, from which the deployment process can retrieve the relevant artifacts.

    Deploy the Same Way Every Time

    An inconsistent deployment process can become a source of configuration drift across environments, especially with the rapid releases common in a continuous delivery system. As a result, valuable time and effort are wasted in identifying and addressing difficulties arising from the application working in one environment and not another.

    For a reliable process in all environments, then, the same set of steps must be repeated from start to finish. This ensures the same results in lower environments, with more frequent deployments (such as integration, QA, etc.), as in higher environments (pre-production and production), with fewer deployments.

    Smoke Test

    Smoke testing deployments is a very rapid way to make sure that the most crucial functions of a program work and will pass basic diagnostics. This non-exhaustive software testing (of all elements, such as services, database, messaging bus, external services, etc.) does not provide the same fine-grain comprehensiveness as full test suites; however, it can be run frequently and quickly, often in a matter minutes (rather than hours or days). This allows for a much quicker turnaround on what can become very time-consuming and basic issues.

    The faster the feedback loop works (especially with automated test tools such as Telerik, QTP, TestComplete), the higher the final product’s quality will be and the quicker it will reach its release-ready state.

    Deploy into a Production-like Environment

    Each new deployment (using, for example, IBM uDeploy, CA Release Automation, XebiaLabs, Automic) should be made into an environment that mimics as closely as possible the actual final production environment. This includes infrastructure, operating system, databases, patches, network topology, firewalls and configuration. By validating software changes in this type of detailed pre-production environment, mismatches and last-minute surprises can be effectively eliminated and applications can be released safely to production at any time.

    Instant Propagation

    Continuous delivery by definition must be an ongoing process of building, testing and releasing. Every check-in to a source control repository should trigger compiling (if needed) and packaging by a build server. This, in turn, should automatically initiate certain predefined testing until the software can either be marked as releasable or returned to development.

    Continuous integration tools (e.g., Jenkins / CloudBees, Bamboo, TeamCity) ensure that cascade of actions along the delivery pipeline is consistent, automatic and instant. Thus, development teams merge developed code and get feedback from automated test tools many times a day, for a more efficient deployment and update process.

    Include the Database

    No list of continuous delivery best practices would be complete without advising that the database be managed using the same basic protocols that ensure secure and reliable source code, task, configuration, build and deployment management. However, many times this is neglected because the database is unlike other software components or compiled code that are easily copied from development to testing to production. Yet, the database is actually a repository of the most valued and irreplaceable asset—our data—and preserving it accurately is imperative to continuous delivery.

    Although the database poses several unique challenges, specialized database tools such as enforced database source control (for all environments), a database build automation tool and database release and verification processes can ensure a stable resource in your DevOps chain.

    Considering these seven continuous delivery best practices will allow you to create a deployment pipeline with increased productivity, faster time to market, reduced risk and increased quality.

    The key to ensuring a quick, robust and accurately repeatable continuous delivery is, as we have seen, automation, deployment consistency, comprehensive testing and database version control. With these fail-safes in place, pushing the “release to production” button can be done much more often and with much more confidence.

    About the Author / Yaniv Yehuda

    yaniv-e1404303491389Yaniv Yehuda is the co-founder and CTO of DBmaestro, an enterprise software development company focusing on database development and deployment technologies. Yaniv is a DevOps expert who spent the last couple of years raising awareness about the challenges surrounding database development and deployment, and how to support database continuous delivery. Connect with him on LinkedIn and Twitter.

     

  • Don’t Leave Software Testers Out of DevOps

    Don’t Leave Software Testers Out of DevOps

    The term DevOps implies that software delivery is all about integrating the development and IT operations teams. But the software testing team is an important, if oft-overlooked, part of the picture. Here’s why.

    Could you deliver software continuously without involving the QA team in the continuous delivery pipeline? You could try, but it would probably not go well. Software testers play a vital role in continuous delivery, for the following reasons:

    They are the glue connecting developers to IT Ops. If there is no one to test the code that developers write, IT Ops cannot deliver a stable product.

    They help find problems before they become costly. If you skimp on integration, unit and performance tests, you won’t find problems in your software until after it reaches users. By that point, fixing those problems will be much more time-intensive than it would if they had been caught early on. Plus, your organization’s reputation will have taken a hit, because problems that could have been nipped in the bud prior to delivery ended up affecting users.

    They know things that developers and IT Ops don’t. If DevOps is all about continuous visibility across the delivery chain, then it only works well when the delivery team’s collective expertise covers all parts of the delivery process. Since developers and IT Ops people are not experts in quality assurance or testing, you need to involve testing professionals in the continuous delivery chain so that they can help everyone else understand the parts of the process that QA professionals know in detail.

    All of the above is to say that if the QA team is not plugged into every stage of the delivery process, your software either won’t be tested efficiently, or it won’t be tested at all. Not testing efficiently means that the QA team is not in sync with the rest of the organization. In this case, the QA team would delay software delivery because it would have to wait on developers and admins to complete its work, and vice versa.

    Not testing at all, of course, is even worse. No one should deliver unvetted software to users.

    Don’t Forget about QA

    The takeaway for organizations seeking to adopt DevOps practices is this: Even though the DevOps conversation on the surface may seem to be about only developers and IT Ops professionals, QA teams play an equally crucial role in continuous delivery. They need to be as involved in the continuous delivery pipeline as everyone else if an organization wishes to reap the full benefits of DevOps.

    — Chris Tozzi