devopsy.kinsta.cloud

Tag: last-mile

  • Continuous Delivery is Not Continuous Deployment

    Continuous Delivery is Not Continuous Deployment

    Every once in a while, it is worth revisiting a topic that flies under most people’s radar. The differences between continuous delivery and continuous deployment is one of those topics. While those steeped in DevOps are well-aware that software can be delivered daily (or even more frequently), deployment is less frequent, and more dependent upon both development and marketing cycles.

    Most CI/CD tools can and do crank out “deployable” apps on a daily basis, or even each time that code is checked in. In theory, each of these builds is a candidate for deployment, and each has had at least some level of testing.

    But setting up the environment to host these apps is a separate step. Quite often today, it is a step that is handled by scripts that configure/move everything to build the app environment into a comprehensive system with knowledge of network, data sources, storage, etc.

    I’m revisiting this topic because new people often hear “CD” and assume that is the end state. Of course, it is not; the application has to be deployed—to Test and Production at least, and in many enterprises to Staging, also.

    While these environments are almost invariably different (Test does not share IP space with Prod, for example), the deployments must mirror each other as much as possible to make Test representative of what Prod will look like.

    As with any step in the DevOps toolchain, scripts to achieve continuous deployment are not a great solution. They are certainly a good first step—automating what previously was done by hand—but tools that make the experience easier and more dynamic are available, and should be considered.

    Whether an explicit continuous deployment tool or an application release automation (ARA) tool (or an ARA that calls a continuous deployment tool, as we’ve seen some used), something to remove dependence on hand-edited scripts is useful for many reasons, starting with the fact that separate scripts are maintained for Test and Prod and changes must be made in two places when a change is made to an application (such as changing where the DB is located or switching to a dedicated AAA server). This makes scripting fragile. Tools can offer shared deployment and custom deployment sections so that multiple changes can be restricted to those things that truly need to be handled separately.

    Deployment is very much a target exercise. The code has been built; deployment is simply giving it a home. Historically, this required agents be strewn about the data center to help target deployments. Increasingly, agentless tools are available that allow the adaptability of continuous deployment while not requiring agents to be installed on every machine that might participate in the deployment activity.

    The other major benefit of moving beyond scripts and into a continuous deployment tool is huge: Everything else is version-controlled, which provides built-in rollback. A developer made a mess of fixing that bug, and things are worse? Roll back the update until the issue can be addressed. Tools such as Git make that particularly easy to do. On the deployment side, the same functionality is required. “Release 7.2 has been deemed to violate GDPR” might require moving back to the previous release. But script-based deployments are always forward-looking. It is enough to modify scripts to reflect the current environment, and it is a rare organization that requires parallel development of backout scripts. However, this functionality comes for free with a continuous deployment tool—that which it has built it can undo, because it is versioned automatically.

    And the benefit of versioning goes beyond rollbacks: It allows multiple version deployments for AB testing and allows for skipping forward and back as far as necessary to meet current goals.

    Is it a panacea? Of course not. Each technology brings new challenges. But continuous deployment solves more problems than it creates. And most of the problems it creates—a desire for greater integration with networking and storage services in non-cloud environments, for example—will be solved in a consistent and repeatable manner by these tools long before any scripting does. Because the tools are designed to create consistent and repeatable results.

    While you are out there kicking it, consider implementing continuous deployment tools to tackle the DevOps last mile. They’ll make your life easier, and your environment less fragile.

    — Don Macvittie

  • Last-Mile DevOps: How to Keep Employees Happy

    Last-Mile DevOps: How to Keep Employees Happy

    Chances are that your company is embracing DevOps to make sure you can get fresh, new digital capabilities to your customers ASAP. That’s because in today’s market, you either have to be first—or quickly close any gaps between you and your more digitally innovative competitors.

    But when it comes to getting new capabilities into the hands of your own employees, things probably move much slower. That’s because your internally facing apps have to clear a hurdle that your customer-facing apps don’t: administration of access privileges that often are poorly defined and inadequately automated.

    That’s a problem. People can’t be productive if they don’t have access rights for the IT resources they need, when they need them. The growing Millennial workforce is going to be especially unhappy if IT is slow to meet their digital needs. And from a security perspective, slow administration of access privileges is also a problem—because your company must be able to automatically and immediately revoke employee access privileges the moment they’re fired or they quit.

    This automated, accelerated management of internal users’ access rights is the missing “last mile” for DevOps. And it’s something you have to address if you’re going to fulfill the needs of the business with the same excellence as you fulfill the expectations of your customers.

    What Makes the Last Mile So Tough?

    If you bank with Chase or ride with Uber, your access to your personal data is gated by your personal login. But, as a customer, you essentially use the same app as everyone else.

    Application privileges within your own company are entirely different for two reasons:

    • Privileges for your internal workforce are much more complex than for customers. Salespeople have sales apps. Your finance department uses finance systems. Your service reps may be allowed to see RMA numbers, but not SSNs. So you must quickly give each person access to only the resources appropriate to their specific role and responsibilities—or risk consequences that include lost productivity, security breaches, compliance failures and excess software licensing costs.
    • Management of internal privileges is an ongoing activity. Productivity, security and compliance demand that you provision each user account for each application with the right privileges at the right time. Privileges must be immediately and appropriately modified every time an employee is promoted or transferred. Privileges must be terminated immediately when someone leaves your company. Privileges may also have to be temporarily modified in real time due to session context—such as use of non-secure public WiFi or an access attempt from a questionable location or at a questionable time.

    Simply put, for internally facing apps, getting code onto a production server isn’t enough. You also need to automate and accelerate management of the “last mile” between servers and employees.

    What Are ‘Last-Mile’ DevOps Requirements?

    DevOps toolchains automate and monitor the software life cycle from design and development through testing and deployment on a production server. What’s missing is automated provisioning and governance of the “last mile” between the server and the individual worker.

    These tasks include:

    • Capture of current user role/responsibility profiles from HR
    • Provisioning of application-specific accounts with profile-appropriate privileges and controls
    • Self-service inputs from authorized LOB managers
    • Detection of session context (network connection, time of day, location, etc.)
    • Real-time modification of privileges based on that session context
    • Automated revocation of access privileges upon termination, transfer, etc.
    • Employee self-service for permitted optional applications and services
    • Monitoring and reporting on employee account activities and events

    Your team probably performs many of these “last mile” tasks manually. Some may also be automated using homegrown scripts. Excessive dependency on scripts is a bad practice, though. Scripts usually are poorly understood by anyone but the original writer—which makes them difficult to maintain and update over time. They also don’t typically integrate well with DevOps, HR systems or other key pieces of the app delivery puzzle. This lack of integration slows your processes down and opens the door for human error.

    Automation of last-mile DevOps makes much more sense. Automation speeds processes, reduces cost and optimizes accuracy. Integrated automation also gives you a dependable, centralized point-of-control for defining and editing policies—as well as for capturing the event logs necessary for compliance and security reporting. The right automation solution will also integrate with the rest of your operations environment (including directories, VDI, and mobile management tools) to ensure secure, reliable application access.

    Why is ‘Last-Mile’ DevOps Important?

    Most business leaders already understand why rapid rollout of customer-facing applications is so important. Unfortunately, many fail to recognize the importance of being just as fast and accurate when it comes to supporting their own workforce.

    The truth, however, is that automation of last-mile DevOps benefits your business in several important ways:

    • Improved employee productivity and engagement. Your workforce will be much more productive and more engaged when everyone has immediate access to the digital tools they need. That improved employee performance will benefit your customers as well.
    • Higher IT efficiency. The sooner you automate the many everyday service provisioning tasks that your skilled IT staff now performs manually, the sooner they can to shift their precious time and energy from routine work to higher-value projects.
    • Enhanced security and compliance. Well-defined access policies, diligent enforcement of those policies with rules-based automation and centralized logging of access provisioning activities all reduce your IT-related risks—as does immediate, automatic and complete revocation of all access privileges the moment any employee or contractor is terminated.
    • Reduced “Shadow IT.” When IT is more responsive to people’s needs, they are far less inclined to turn to alternative digital resources that aren’t properly monitored, governed or secured.
    • Greater business agility. M&A, reorgs and other organizational moves are chronically bottlenecked by manual execution of mass changes to the workforce’s digital access privileges. Rules-based automation of last-mile DevOps eliminates this agility-killing process friction.

    The bottom line: To achieve true digital agility, your company must automate the “last-mile” tasks that give your people access to the IT resources they need—when they need them.

    About the Author / Stacy Leidwinger

    stacy-leidwingerStacy is the VP of Products at RES where she is responsible for defining overall product direction, roadmap and positioning, to drive product excellence, company growth and customer success in the areas of end user computing and security. Her background is in both product marketing and product management helping to positioning B2B software companies for growth and market leadership. Prior to RES, Stacy led the product management team at Directworks, a cloud-based sourcing and supplier management solution. Before Directworks, she managed the roadmap, product positioning, and go-to-market strategy for Vivisimo, an enterprise search solution, which was acquired by IBM. While at IBM, Stacy was responsible for the integration of Vivisimo’s product line into IBM’s big data portfolio. Connect with her on LinkedIn / Twitter.