devopsy.kinsta.cloud

Author: Shridhar Mittal

  • Building Security and Compliance into the SDLC

    Building Security and Compliance into the SDLC

    As the concept of DevOps has become more popular in recent years, there are some common themes that always seem to come up in discussions about it. For example, how often do we talk about ways to speed up the software development life cycle (SDLC) in order to bring innovative applications to market faster and meet ever-increasing customer demands?

    As important as this and other popular DevOps themes may be, though, they often have the side effect of overshadowing some of the less glamorous topics, such as security and compliance, which is often viewed as a sort of “necessary evil.” That said, the risks of putting an unsecure application into production can create massive challenges for organizations – from breaches to loss of company IP to brand damage – making security and compliance a topic that must be tackled as enthusiastically as accelerating innovation.

    Three Critical Areas of Focus

    When it comes to considering how security and compliance can become more integrated with DevOps practices, there are three critical areas on which all organizations should focus: shifting security left in the SDLC, building security into policies and creating an audit trail throughout development.

    Shifting Security Left in the SDLC

    Organizations that incorporate security in the earliest stages of the SDLC will ultimately benefit from products and applications that are secure by design. But in order to accomplish this, they can’t wait until the software hits production to test it for vulnerabilities.

    Service virtualization can help by simulating the application delivery run-time environment and its data, allowing developers and testers to focus on security immediately, instead of waiting for access to crucial resources. In addition, a release automation tool can help collapse development cycle times from days to minutes, enabling IT teams to spend more time improving the functionality, quality and security of their applications – and less manually promoting them from stage to stage.

    Building Security into Policies

    It used to be that every element of application development took place between an organization’s four walls, but with the rise of cloud and software-as-a-service (SaaS) technologies, it’s not uncommon for different stages of the SDLC to occur on different infrastructures. So if the environments are always changing, how do we ensure security is consistently addressed? By building it into the policies that comprise our continuous validation methodologies.

    Release automation enables development teams to create policy-driven infrastructure provisioning rules that automatically determine what application elements can and cannot be staged on specific infrastructure types. For example, a common policy would be to never let customer or database information move to a public cloud environment, where sensitive information could be lost or stolen.

    Creating an Audit Trail through Development

    To this point we’ve centered the conversation mostly on security, but being able to maintain – and prove – compliance throughout the SDLC is an equally important challenge that IT development and operations teams must solve.

    So when we think about compliance, we’re really asking questions like “What application moved from this stage to that stage?”, “Who released the application into production?” and “If there was a rollback, what was the cause and who rolled it back?” In other words, we’re talking about audit trails and logging all activities within the SDLC – something that can be difficult when numerous manual steps are involved. However, a release automation tool will capture all of this data as a matter of course as it automates release deployments through orchestration and promotion of applications from development through production. This means you’ll always be able to answer those who, what, where and when questions that pop up during audits.

    Eliminating Vulnerabilities and Getting Back to the “Good Stuff”

    I’ll admit that security and compliance are not the most exciting topics in DevOps. If application development were a meal, they’d be the pile of lima beans you have to eat before you get to the dessert that is innovative feature development. The good news is, service virtualization and release automation tools can help you speed and simplify the process of building security and compliance into the SDLC, which ensures your applications will hit the market without vulnerabilities – and lets you get back to the fun stuff.

  • Two Ways DevOps Unlocks the True Potential of Agile

    Two Ways DevOps Unlocks the True Potential of Agile

    In a recent post on InformationWeek, Erik Weber, a professional Scrum trainer and Agile expert, explores four signs that you’re doing Agile development wrong. Upon finishing the article, I was reminded that Agile in theory is often very different from Agile in practice, and when that gap exists within IT, it can have massive consequences on both development operations and the business.

    At the risk of stealing some of Mr. Weber’s thunder, I’m going to spoil the first two signs he discusses – namely, “failure to ‘get done’” and “failure to launch” – because I believe they are common challenges for many IT groups. The good news is, organizations can close their gaps and realize the true value of Agile development by incorporating DevOps processes and tools into their systems development life cycle (SDLC).

    Getting to “Done” Faster

    “If it takes you longer than a few weeks to turn an idea into a production-ready feature, you are not Agile – full stop,” says Weber, and I would agree. The whole point of Agile was to move away from the slow, monolithic development methodologies of the past by breaking the process into smaller chunks and having developers, testers and business development people working concurrently to speed new features to market. Most Agile practitioners would say they’re doing just that, but many are still not “getting to done” as fast as they would like. Why is that?

    According to Weber, the biggest problem is that many IT groups leverage Agile techniques for development, but then do all of the testing at the end. Obviously, this creates numerous problems that can delay project completion. As we all know, the later bugs and glitches appear in the SDLC, the longer it takes to fix them. When that happens, costs go up, delivery pushes out and customers are unhappy.

    The DevOps principle to employ here is getting the operations team involved in testing earlier in the SDLC – essentially shifting their work left – and the tool that can help is service virtualization. By simulating constrained or unavailable systems across the SDLC, service virtualization enables developers, testers and performance teams to work in parallel for faster delivery and higher application quality and reliability. With DevOps, they can realize truly parallel Agile development without constraints – and ultimately get to “done” faster.

    From “Failure to Launch” to Continuous Delivery

    “If you haven’t actually released your software to production – and on to customers – for three or more months, you are missing the big picture,” argues Weber. He believes that many product managers and executives hold back official product releases because they “must have all the features,” and when this happens, they forfeit the ability to both get new features into customers’ hands on a regular basis and react more nimbly to their wants and needs.

    There are numerous reasons why the “all features” mindset persists, but a good way to prove its obsolescence is by incorporating the DevOps principle of continuous delivery into the development process. Continuous delivery means always being in a ready state for pushing applications and services through the SDLC and into customers’ hands – and release automation is the tool that helps organizations reach that state.

    Release automation enables continuous delivery by automating complex, multi-tier release deployments through orchestration and promotion of applications from development through production. As a result, visibility improves across an organization’s deployment chain, giving it the flexibility and agility to continually release new features to market and react quickly to changing market demands. Once an IT organization reaches a state of continuous delivery, it becomes easier for executives and product managers to pull the trigger on a given release – because they know that the next one isn’t far behind.

    Agile is as Agile Does

    Weber offers four signs of ineffective Agile development in his article, but I would argue that there is a unified idea running through them all: It’s not enough to employ Agile practices; you have to follow through until you meet your Agile goals. Ask yourself, “Are we really delivering releases to market faster, at a higher quality and at lower cost to the business?” If the answer is “no,” the right DevOps methodologies and tools might be just what you need to put these failures behind you and finally realize the true value of Agile development.

  • Your End Users Want Everything: Here’s How to Give it to Them

    Your End Users Want Everything: Here’s How to Give it to Them

    In today’s application-centric business environment, the end user is king. Whether we’re talking about being first to market with the next big thing or adding new capabilities and features to an existing application, so much of our current development time, resources and energy is spent on trying to meet the needs of end users.

    It’s not difficult to see how we got here. The proliferation of social media and mobile and other connected devices has empowered end users to make their voices heard – and whether their opinions are positive or negative, we have no choice but to thoughtfully consider them if we want to produce market-leading applications.

    At this point, you might be thinking, “How is this different? End users have always been king.” You’re right, but the difference between then and now is that we used to build roadmaps and select features based on what we thought they wanted. Now, thanks to social forums, user reviews and other avenues for collecting feedback, we know exactly what they want. The trick, of course, is finding ways to deliver on that knowledge quickly and at a high level of quality without breaking the budget.

    Taking Agile to the Next Level

    Agile was one of the first methodologies to incorporate user feedback directly into development. You know the drill: choose a small set of capabilities to develop, release the build to a select group of users, collect and incorporate feedback into another build and continue iterating until the application is ready for production.

    One of the goals of DevOps – which CA defines as best-practice application delivery methods that improve communication, integration and collaboration between development and operations – is to enable Agile-like development practices that incorporate end-user feedback from after an application is on the market.

    We talked a bit earlier about collecting such feedback. Whether you read forums, poll customers or even collect usage data directly from the application, you know that getting the feedback isn’t the hard part – it’s incorporating that data into the development lifecycle in a way that meets your speed, quality and cost requirements.

    Starting with Pace-Layered Approach

    When it comes to being nimble in the software development lifecycle (SDLC) and reacting to the marketplace, one of the challenges many enterprises have is that their IT infrastructure is complex, comprised with legacy and modern technologies that have been assembled over time. According to a major analyst firm, the key to speeding development in such environments is to segment the infrastructure into layers: namely, systems of record, systems of differentiation and systems of innovation.

    For systems of record, think foundational technologies like mainframes that have typically lengthy development periods, versus systems of innovation, such as mobile apps or cloud services, that have a lighter footprint and are more flexible. Once you’ve categorized your components into these layers, you’ll be able to react to customer feedback most quickly with your systems of innovation – and there are two types of tools to help you do just that.

    Application Delivery Tools That Speed Development and Delivery

    With a service virtualization tool, you can simulate constrained or unavailable systems across the SDLC, allowing developers, testers and performance teams to work in parallel for faster delivery and higher application quality and reliability. In other words, service virtualization enables you to decouple your systems of innovation from the slower moving systems of differentiation and record, so you can quickly deliver on customers’ requests, even amidst all the change and complexity in your IT environment.

    To further accelerate the SDLC, a release automation tool can automate complex, multi-tier release deployments through orchestration and promotion of applications from development through production. This tool is your assembly line, driving the application from code development to production, so you can get new innovations into your customers’ hands faster than ever before.

    Addressing end-user feedback is an ever-evolving, constantly moving target. But if you follow Gartner’s pace-layered approach and plug your systems of innovation into the right application delivery tools, it’s a target you’ll always be able to hit.