devopsy.kinsta.cloud

Tag: agile development

  • Yes, Software Development is an Assembly Line, but not Like That

    Yes, Software Development is an Assembly Line, but not Like That

    I grew up in a manufacturing town. Nearly everyone worked for (or previously worked for) the local textile factory. My father was no exception. He had a few jobs but eventually landed a management job at the factory and started working closely with the engineers and other plant operators. At the time, I was in high school and about to start my education in software development. At the time, I felt–maybe hoped–that my world and the world my father was steeped in were vastly different. I was working on cutting-edge technology in the software space while he was helping design and run decades-old manufacturing facilities. It took years to learn that wasn’t the case.

    Agile Software Development

    I was lucky to be able to learn about software engineering while also hearing my father learn about lean manufacturing at the same time. In the beginning, I failed to see the connection between them, but as I learned and read more about this relatively new “agile” thing, I started to see the big picture. It should come as no surprise to folks that agile software development grew out of manufacturing systems developed for exactly the same reasons–to build things more efficiently.

    That same desire to deliver value faster at a lower cost drives much of the innovation and growth in every business, including software companies. It’s not surprising that key leaders in the industry found those impressive innovations in industrial engineering and began adapting them to software. We know that waterfall and agile were adopted from industrial engineering, and the next big software development innovation will likely be as well.

    Improve Business Efficiency

    We can see many of the agile processes directly map back to either lean philosophy or even older industrial processes. Just-in-time manufacturing, or the idea that you keep an extremely limited number of raw or intermediate materials, is a philosophy that focuses on narrowing your manufacturing process to the essentials. Most agile practitioners argue similarly that your stories and shipped features should be as small as possible to deliver only the value required by the user. Both systems aim to improve business efficiency and agility by reducing potential waste (material breakage, for one, and over-engineering for the other).

    All of these parallels make perfect sense to me. However, there was one component that never really clicked. A ticket and a widget are incredibly different things. Let’s explore this difference in two ways.

    Traditional manufactured goods are usually tangible things. Tangible things often provide value for a fixed amount of time to a single user. For example, a delicious baked snack I pick up on a road trip provides maybe 30 seconds of value when I get back in the car; however, that car may provide 30 years’ worth of value to multiple users. Features in a software platform similarly provide value to users that vary in scale and duration. Here’s where we find an interesting divergence. A good provides a set amount of value and is often produced in bulk; a feature in a SaaS platform is often produced once and can provide an unbounded amount of value.

    Compare and Contrast

    Another way to see the contrast between the types of products is to look at the differences between engineers in each discipline. In a traditional manufacturing environment, the engineers are not the people actually operating the machines to produce the widgets. The engineers design the manufacturing lines and the products that will be produced on them. In software engineering, the engineers are the ones producing the features. Curious.

    However, if we look closely at the two roles, we see that they are actually producing similar things. Manufacturing engineers produce assembly lines and manufacturing processes that can produce those units of value. Software engineers are largely the same, also producing systems and processes that deliver units of value. The manufactured widget of software is actually the discrete user interactions with those features and pieces of software, not the features themselves. The assembly line in software engineering isn’t, as many think, the engineers producing features. Rather, it’s software producing value-creating experiences for users.

    While this is interesting, how does it help us? I’ll propose two key ways.

    Manufacturing processes are extremely adaptable to managing the technology and platform. Systems like Total Quality Management, which are focused on driving a cultural mindset of continuous improvement and an entire company focused on providing very low defect rates, easily translate to customer satisfaction in software organizations. Just to pick on TQM a bit, if we were to adapt it to software, we would focus on the number of times users are impacted by a defect more than the number of open bugs. Instead of tracking the number of defects and searching for more, we would be tracking the number of users who either failed to receive the promised value from the product or had severely diminished value. That would drive investment not only at the engineering level but would create buy-in from the whole company. Everyone in the company is interested in a conversation about how many users aren’t able to gain value from a feature, but many fewer are interested in how we go from 20 open bugs to 10 open bugs.

    Secondly, this mindset shift can help bridge the expectation gap between engineering and the business. I’ve been a part of many conversations where engineering has discovered a potentially serious flaw, and the whole team is in agreement that this is potentially one of the most serious bugs we’ve found in a while. However, when they bring this issue to the business side, that passion gets quickly overruled if engineering can’t show that that bug is “impacting customers.” Those debates often fall into conversations of projected odds better left to the sportsbook room in Las Vegas. While there are obvious exceptions for security exploits, compliance issues, and other business risk-driven defects, the business is justified in not investing in fixing a defect that users aren’t impacted by.

    Reporting Performance Issues

    Conversely, this line of thinking can help engineering convince the business that something is a critical problem and needs to be addressed. While previously, I would have reported performance issues in terms of p99 times or average load times, that doesn’t describe performance in terms of our unit of value. If our unit of value is a customer using our app or a feature, then each negative interaction is a broken widget. As an example, I’ve since taken to reporting performance issues in terms of the number of sessions with a frustratingly long load time and the number of clients and users that are experiencing those.

    Manufacturing is perhaps the most varied industry in existence, adapting itself to produce nearly everything from food to raw materials to consumer electronics to clothing. That long history, many contributions from a massive number of brilliant engineers, and significant innovation have led to dozens of amazing systems for delivering value. While I proposed two examples of how we should give these processes a second look as engineering and business leaders, it’s worth dusting off some manufacturing engineering books and giving them a read yourself. You may find the key to outpacing your competitors was drawn up by an industrialist decades ago.

    My first college internship was at one of the factories my father worked at in the engineering department. I was able to see firsthand how deeply some of today’s engineers think about these types of production processes. They really know how to ship stuff, and software engineers may have a lot to gain by learning from them.

    Now, go build great things!

  • How to Secure C-Suite Buy-In for Your DevOps Efforts

    How to Secure C-Suite Buy-In for Your DevOps Efforts

    You could be forgiven for assuming DevOps is the modus operandi only for big modern enterprises like Tesla and Uber, but this is not the case. DevOps builds on earlier approaches, such as Agile development and Lean methodology, by emphasizing the importance of collaboration between development and operations teams and the use of automation to streamline the software development process.

    So, while the term “DevOps” is relatively new, the principles and practices that it encompasses have been in use for many years.

    In a traditional waterfall model, the software development process is split into distinct stages, with each stage being completed before moving on to the next one. The development and operations teams work in separate silos, with little interaction between them until the end of the development process when the finished product is handed over to the operations team for deployment and maintenance.

    Benefits of DevOps

    In contrast, a DevOps model emphasizes collaboration and communication between the development and operations teams throughout the entire software development life cycle. The goal is to create a culture of shared responsibility for the success of the project, with both teams working together to ensure that the software is developed, tested and deployed quickly and efficiently.

    DevOps also emphasizes automation, with the use of tools and processes to streamline the aforementioned project tasks. This automation helps to reduce the likelihood of errors and allows the teams to focus on higher-level tasks.

    Overall, the key differences between DevOps and a traditional waterfall model are the emphasis on collaboration and communication, the use of automation and the focus on shared responsibility for the success of the project.

    In short: Speed, time to market, agility and cost savings.

    What’s Driving DevOps Transformation?

    Any company, regardless of size, can release faster with DevOps. Look at the agile FinTech success stories; look at the generative AI success stories. In terms of cost savings too, it’s not ‘How much am I paying for 10 people, 20 people, 100 people…?’ From a DevOps standpoint, cost means penalties avoided from failing to release on time, project delays and project poor quality.

    Overall, development practices are evolving. Some clients call DevOps ‘zero rework’ development, others refer to it as ‘shift-left development.’ Whichever term you prefer, the context is the same: They want faster release and to reduce duplication of work. The way to achieve ‘shift-left’ or ‘zero rework’ would be through DevOps transformation. All of the individual pillars of DevOps concern shifting left, causing them to release faster and achieve their cost optimization.

    However you refer to it, DevOps is mainstream because of its scalability benefits, as well as the agility to react to unforeseen situations during development, QA or operations. This equates to competitive advantages and future-proofing.

    Challenges of Implementing DevOps

    Every business is different, but many of the challenges are the same. One of the main challenges is understanding your company’s specific blend of pain points on its road to DevOps transformation. Common challenges include:

    Vision – DevOps is not a top-down initiative. The role of executives in DevOps is to define a vision; if the vision is not clear, you won’t have buy-in. You can have the best tools and technology but if you don’t have buy-in, then it won’t work.

    Investment – DevOps is a change in every aspect of people, processes, technology and culture. You can’t just bring in this change with zero investment. It’s not unusual for costs to go up for the first couple of years after moving to DevOps because you’re transitioning from manual testers and normal developers to fungible team members that come at a premium. The cost advantage shows up after at least a year as rework goes down and the quality of release incrementally increases, leading to a better customer experience. So, it’s self-funded from the efficiencies it will bring in … but only if you persevere.

    Celebrating Success – Too many people try to boil the ocean with DevOps transformation. This leads to frustration, misaligned teams and, eventually, poor results. If you start small with DevOps transformation, it soon shows its superiority as a business model. This inspires your leadership and your executive teams to see the benefit of DevOps and buy into it by osmosis rather than taking the word of that executive with a big idea and a big purchase order.

    Culture and People – This is more than just a technology play. In fact, technology is the easy part. People, processes and culture all need to transform to implement DevOps. You need to move from a project to a product-based methodology. From a people perspective, you can’t bring in manual testers or manual validators to do DevOps. Any successful DevOps implementation has to get this right.

    How to Implement DevOps: The Hub and the Spoke

    Again, start small. You could start with only continuous integration and then move on to add continuous deployment. If you start over aspirationally, you are more likely to fail and go back to the old ways. As you expand DevOps gradually, you can follow the hub and spoke model.

    In the hub and spoke model, the hub is a lean team responsible for setting up the tools, automation and best practices. The hub is responsible for defining what is to be executed. The spoke, on the other hand, is responsible for execution. The spoke is the extended team and their individual projects which they are responsible for executing.

    The hub is also responsible for enablement by defining what processes, best practices, tools and pipelines should be used. Teams in the spoke will use the pipeline to promote their goal from development to QA, from QA to staging and from staging to production.

    Next-Gen DevOps

    The evolution of DevOps continues even for early adopters, especially with the introduction of AI and generative AI. How do you use AI to validate your requirements? How do you use AI to decide what infrastructure is needed and when? How can you use AI to optimize your test sets? Next-gen DevOps is about smarter DevOps and intelligent DevOps.

  • Documentation in Agile: Challenges and Trends in 2023

    Documentation in Agile: Challenges and Trends in 2023

    Agile documentation refers to the creation and maintenance of documentation in an agile software development process. It emphasizes “just enough” documentation that is necessary for the current iteration, preferring documentation that responds to specific needs over extensive upfront documentation. The goal is to provide clear and concise information to support the development team while keeping the documentation flexible and updating it as needed throughout the development process.

    In this article I’ll present the state of Agile documentation and how it is expected to evolve in 2023 and beyond.

    What Does an Agile Approach to Documentation Look Like?

    An agile approach to documentation looks different from traditional, waterfall-style documentation practices in several ways:

    • Emphasis on just-in-time documentation: Agile prioritizes documentation that is created and updated as needed, rather than extensive upfront documentation.
    • Collaborative and iterative: Agile documentation is created and maintained through collaboration between the development team and stakeholders, with a focus on continuous improvement.
    • Flexible and adaptive: Agile documentation is designed to be flexible and adaptable, allowing for changes and updates as the project progresses.
    • Minimalistic: Agile documentation focuses on providing just enough information to support the development process, avoiding unnecessary detail.
    • User-focused: Agile documentation is centered around the needs and perspectives of the users and stakeholders, rather than the development team.

    In practice, an agile approach to documentation might involve user stories, wikis, and documentation that is integrated into the development process rather than treated as a separate task.

    7 Agile Documentation Challenges

    Teams attempting to write and update agile documentation can face several challenges, including:

    1. Balancing speed and detail: Agile documentation is meant to be lightweight, but it also needs to be detailed enough to support the development process. Striking the right balance between speed and detail can be challenging, especially as the project evolves and requirements change.
    2. Keeping documentation up to date: Agile projects are highly iterative, which can make it difficult to keep documentation up to date. Documentation that is not updated regularly can become outdated or irrelevant, causing confusion and slowing down the development process.
    3. Maintaining consistency: In an Agile development process, multiple team members may contribute to documentation, which can make it challenging to maintain consistency in style and format. This can result in documentation that is difficult to navigate and understand, which can slow down the development process.
    4. Managing collaboration: Collaboration is a key part of the Agile development process, and it is important for team members to be able to share information and feedback on documentation. However, managing collaboration effectively can be challenging, especially when team members are located in different locations or time zones.
    5. Prioritizing documentation: In an Agile development process, there is often a lot of pressure to prioritize development work over documentation. This can make it difficult to allocate sufficient time and resources to documentation, which can result in documentation that is incomplete or of poor quality.
    6. Dealing with changing requirements: Agile projects are highly iterative, and requirements can change rapidly. This can make it challenging to keep documentation up-to-date and relevant, as documentation that was created to support one set of requirements may no longer be applicable as the project evolves.
    7. Ensuring documentation is accessible: Agile projects often involve multiple team members and stakeholders, and it is important for documentation to be accessible and usable by everyone. Ensuring that documentation is stored in a centralized, easily accessible location can be challenging, especially in large or complex projects.

    Agile Documentation Trends in 2023 and Beyond

    Here are some of the key trends in Agile documentation that can help your organization improve your process and overcome the challenges above.

    Documentation Automation

    Documentation automation refers to the use of technology to automate the creation, maintenance and updating of documentation. This can involve the use of tools that generate documentation based on code, data or other sources, as well as tools that streamline the collaborative creation and review of documentation.

    In an agile development context, documentation automation can help to increase the efficiency and accuracy of documentation while freeing up time for the development team to focus on other tasks. It can also facilitate the creation of consistent, up-to-date documentation that is always in sync with the latest changes to the code or other project assets.

    Some examples of documentation automation tools include:

    • Automatic code documentation generators that extract documentation from the source code and generate reference documentation.
    • Wiki and documentation management tools that allow for the creation, editing and collaboration on documentation.
    • Automated testing and reporting tools that generate documentation on test results and project progress.

    Documentation-as-Code

    Documentation-as-code (DaC) refers to the practice of treating documentation as a first-class artifact in the software development process alongside code and other project assets. This approach aims to integrate documentation into the development process, making it easier to manage, version and maintain.

    Documentation-as-code can be achieved through a variety of methods, including:

    • Storing documentation in version control systems, such as Git, alongside the code to ensure that documentation is versioned and backed up along with the code. This is especially compatible with a GitOps development process.
    • Using markup languages, such as Markdown or reStructuredText, to write documentation, making it easier to format and display the documentation and to convert it to other formats if needed.
    • Automating the generation of documentation, such as API reference documentation, based on the code.

    The goal is to make documentation a more integral part of the development process, reducing the effort required to create and maintain documentation and improving the accuracy and usefulness of the documentation. 

    Continuous and Collaborative Documentation

    Collaborative documentation refers to the practice of involving multiple stakeholders, including developers, product owners and end users in the creation, maintenance and review of documentation. This approach emphasizes collaboration and communication as key elements of the documentation process.

    In an agile development context, collaborative documentation is seen as a way to ensure that documentation is relevant, up-to-date and meets the needs of all stakeholders. This can be achieved through a variety of methods, including:

    • User stories and other agile documentation techniques that involve end users in the documentation process.
    • Collaborative authoring and review tools, such as wikis and online document editors that allow multiple stakeholders to contribute to and review the documentation in real-time.
    • Regular retrospectives and other agile processes that provide opportunities for the development team to review and improve the documentation.

    The goal is to create documentation that is accurate, relevant and useful to all stakeholders, while also fostering communication, collaboration and continuous improvement within the development team. 

    Interactive Documentation

    Interactive documentation refers to the practice of creating documentation that is designed to be interactive, allowing users to engage with the information in a dynamic and engaging way. This can include elements such as interactive examples, simulations and tutorials, as well as tools that allow users to experiment with and explore the documentation.

    Interactive documentation can provide a number of benefits, including:

    • Improving the user experience by making the documentation more engaging and accessible.
    • Facilitating a deeper understanding of the product by allowing users to experiment with and explore the documentation in a hands-on way.
    • Improving the accuracy and usefulness of the documentation by allowing users to provide feedback and suggestions for improvement.

    Interactive documentation can be achieved through a variety of methods, including:

    • Interactive tutorials and examples that demonstrate how to use the product.
    • Simulations and prototypes that allow users to experiment with the product in a safe and controlled environment.
    • Tools for creating and maintaining interactive documentation, such as online document editors and wikis.

    Conclusion

    In conclusion, documentation is an essential aspect of the software development process, and agile development has brought about new trends in the way documentation is created, maintained and used. From documentation automation to interactive documentation, the agile approach is focused on improving the quality and usefulness of documentation while also reducing the administrative burden on the development team. 

  • Best Practices to Improve your Engineering Sprints

    Best Practices to Improve your Engineering Sprints

    What is the purpose of sprints? We break work into sprints so we can more easily monitor, estimate and predict what we want to ship and when. Over the years, engineering teams have gotten used to moving quickly from one sprint to the next, but I think it’s important to be more thoughtful in how we plan and execute sprints.

    Running effective and successful sprints can define whether or not your organization is able to ship high-quality software fast and often. It also gives teams more flexibility and the ability to quickly change something that is not working or, on the other hand, to iterate on a successful technology. 

    After almost 20 years as an engineer, manager and as a CTO, I have found there are several best practices that improve the sprints that are part of my team’s software development life cycle. 

    Sprint Planning

    When planning a sprint, there are several things to keep in mind.

    Make Sure the Work Aligns with Business Priorities

    There are always a number of elements an engineering team can focus on during any given sprint. It’s fairly easy to lose sight of the business’ end goal. Make sure to gut-check to make sure that the sprint goals align with current business priorities.

    Ensure the Workload is Balanced From the Start

    This seems like an obvious statement, but make sure team members have equivalent workloads so you avoid burnout. It is also important to understand how different engineers on the team work—some people work best by selecting their own tasks with items that are unassigned, some pick up unfinished tasks as they finish others and some prefer to be assigned certain tasks because they have specialized skills. 

    Don’t Underestimate the Time That Interruptions/Additions Take 

    Along the same lines as the above, don’t overlook this for several reasons. Without adequate, data-driven insight into the actual state of each team member’s workload, it is almost impossible to gauge what’s happening in real-time. While business-critical sprints are assumed to take priority, side projects, Slack interruptions and meetings can easily consume an engineer’s day. Make sure to proactively check that each member has enough true deep work time without becoming burned out. 

    Don’t Underestimate the Time it Takes to get Things to a Done State

    Sometimes engineering teams only look at the development stage, but the full cycle required for the software to get to the end user might take longer. Allotting the right amount of time to get the job done across all phases of development will help avoid unexpected surprises. 

    When You Get to Mid-Sprint

    Monitor Unplanned Work

    Initial planning doesn’t necessarily take into account the bugs and fire drills that will likely arise after the sprint starts. Pay close attention to any mid-sprint additions and adjust as necessary. There may be team members who have cleared their sprint queue and are capable of taking on this work, but being aware of team members’ workloads at every stage is critical. 

    Do Daily Stand-Ups and Raise Flags as Early as Possible

    This will help anyone encountering roadblocks so a small issue doesn’t turn into a huge bottleneck. If you look closely at your PR cycle time, you will find a ton of insights about where roadblocks often happen. Using historical data during sprints can also go a long way toward helping identify potential bottlenecks, allowing you to proactively avoid friction by delegating reviews or setting out additional time for approvals. 

    Get Ahead of Burnout

    The tech industry has a turnover rate of 13.2%—pretty high when compared to other sectors. But the reality is that it can be really difficult to identify burnout without hard data. Don’t wait until people start speaking out about being overworked: Burnout prevention should be a full-time focus. Before sprints, make sure people aren’t coming in with high levels of fatigue and make sure that overtime doesn’t routinely increase throughout.

    Use Sprint Progress Estimations to Reprioritize

    Each sprint starts off with a set workload, but in reality, every sprint is dynamic. Take a look at each day’s progress and evaluate if your team is ahead of or behind schedule. If you are on track to finish a majority of the work, you can anticipate a successful sprint end. If not, don’t worry; you can always recommend that your team recalculate priorities. Engineering managers can take this time to load-balance some of the heavier work and shift goals to the next sprint as needed. Staying flexible while maintaining a clear view of what is actually happening during the sprint, will inevitably result in success. 

    At the End of the Sprint

    Do a Thorough Sprint Retrospective 

    As a team leader, you should constantly be thinking about how things are going and how people are feeling. If you can, use hard data to look at things like time allocation, PR throughput and any items added mid-sprint. Taking notes throughout the sprint will help remind you of any issues that came up, and you can discuss ways to improve for next time. Each sprint is a chance to learn; the more you learn, the better the sprint and the better the product will be for end users. 

  • How DevOps Tools Are Contributing to Automation Initiatives Across the IT Landscape

    How DevOps Tools Are Contributing to Automation Initiatives Across the IT Landscape

    Prolific advancements in IT, specifically in agile methods and culture over the years, has led to burgeoning needs for a more holistic end-to-end software delivery approach. Agile development is an umbrella term that encompasses numerous incremental and iterative software development practices — including Kanban, SAFe (Scaled Agile Framework), Scrum, Extreme Programming (XP), Lean Development, among others.

    Each methodology works on its own unique approach. However, the core commonalities they share lie mainly in their values and vision. The methodologies integrate continuous feedback from iteration to refine and deliver a successful software system. They include various forms of continuous evolution, such as continuous integration, planning and testing, of both software and project. Furthermore, one of the most significant aspects of agile methodologies is their keen focus on empowering workforces to work together and collaborate more efficiently, thus simplifying and speeding up decision-making processes.

    Advancement in agile development is what has birthed the DevOps culture. The technology is born from the rising need to adapt to increasing software velocity and throughputs generated through agile methods.

    Understanding DevOps

    The DevOps market consists of a set of practices, designed to integrate and automate processes between IT and software development teams, enabling them to create, test and deploy software in a quicker and more efficient manner.

    The term DevOps, which was coined in 2009 by Andrew Clay Shafer and Patrick Debois, is a combination of the words “development” and “operations.” It is also indicative of a cultural shift in the IT sphere, which bridges the gap between historically siloed teams, such as operations and development.

    The DevOps framework essentially adopts a culture where the critical focus is on facilitating collaboration between the business, operations and development teams. Although tools are considered as pillars of the technology, DevOps is designed to deliver continuous value for customers, empower organizations to provide solutions of the highest quality at swift rates, and bring about the automation of the entire business process spectrum, from building to deployment of a product or application.

    Shifting Trends Toward Automation in Software Development Processes and the Subsequent Impact on DevOps Adoption in the IT Space

    The software development process consists of several integral parts, among which testing is a crucial task. It allows developers to monitor the functionality of the software, monitor and register performance, and detect any aspects that require remediation. However, with software projects becoming increasingly more complex as the years progress, and with project development life cycles accelerating, conventional methods of manual QA (quality assurance) testing fall short in meeting testing objectives within the desired time frames.

    Consequently, software developers are shifting their focus toward automated workflows and testing tools, in order to expedite testing routines without compromising on consistency and completeness in QA processes.

    DevOps practices are significantly dependent on automation to ensure frequent and timely deliveries across platforms. Studies have shown that nearly 85% of IT leaders claim that automation is a critical aspect of their DevOps strategies. This is attributed largely to the fact that automation empowers infrastructures to successfully field constant changes in codes that are associated with DevOps tools. 

    Furthermore, automation allows the effortless scaling of environments and unburdens skilled workforces from mundane and repetitive tasks, enabling them to focus on more integral aspects.

    Considering a process perspective, automation in testing involves the addition of test automation actions and tools to regular software development regimens. For instance, new builds delivered to a repository can be automatically subjected to automated testing procedures using a number of prescribed tools, with little to no need of developer intervention. The results are recorded with care, then compared to previous test runs and eventually submitted for review to developers. 

    Depending on the outcome, the software can then be cycled back to the developers for further remediation or approved for deployment. This is especially relevant in terms of the DevOps framework, which relies on continuous integration/continuous delivery (CI/CD) pipelines.

    CI/CD pipelines are a prominent outcome of developer operations, allowing developers to validate the quality of the software with minimal intervention, and deploy apps and software to customers in a quicker manner.

    CI/CD platform CircleCI, for example, has recently raised over $100 million in Series E funding, in an effort to boost the development of their DevOps product suite. This move is indicative of CircleCI’s proficiency in delivering an automated approach to DevOps practices, including tools for companies to create, test and deliver software.

    How Is the Current Pandemic Impacting Digital Development?

    The COVID-19 pandemic has asserted a massive influence on the industrial landscape, driving workforces across the globe into remote-only work set-ups. With millions of people working from home for a seemingly indefinite period, enterprises across the globe are rallying to accelerate automation efforts in order to more efficiently deliver digital business applications to engage their employees from remote workspaces.

    According to various studies, nearly 73% of IT operations and DevOps teams are working toward maintaining and expediting initiatives for digital transformation throughout the current crisis, holding the belief that the value of digital offerings is set to witness a positive growth trajectory in the social distancing era.

    DevOps industry players such as JFrog are working toward providing enterprises and teams with access to cloud-based DevOps technologies, free of cost, particularly those which are undertaking active research and response efforts to combat the COVID-19 pandemic. These DevOps technologies include Pipelines, Xray and Artifactory, among others.

    While the exact impact of the global crisis on the DevOps environment in particular and the IT space in general is yet unclear, it is becoming more prominent that the strong focus on the prevention of such crises in the future — both in and out of the IT realm — is likely to set a great precedent for the growth of the DevOps industry in the years ahead.

  • DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

    DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

    Despite most developers and managers being well aware of the concept of DevSecOps, it is still often confused with a number of related processes and concepts. This is particularly true for the Department of Defense (DoD) contractors because they have long been encouraged to use a related process known as agile development. 

    Since agile development has been around for more than a decade, there is a tendency for organizations to regard DevSecOps as an extension, or even a synonym, for it. In reality, though, the two approaches are distinct. The objectives of both approaches are similar: balancing speed and agility, detecting risk early and both focus on cloud-native security and performance. 

    However, while DevSecOps does build on some agile development principles, such as the continuous integration and delivery of software systems in cycles, its key emphasis from the beginning of the process is to integrate security features, while Agile only focuses on delivering software.

    In this article, we’ll look at the key differences between agile development and genuine DevSecOps processes, and how each complements the other.

     

    DevSecOps vs. Agile Development

     

    The difference between DevSecOps and agile development methodologies can be understood in reference to one aspect of software development: security. When, where and who implements security in software development varies between the two approaches.

    Agile development methodologies focus on iterative development cycles, in which feedback is continuously reintegrated into ongoing software development. However, even in mature agile development processes, security is still often added to software as an afterthought. This should not be read as blaming software developers for often underestimating the potential harm from malware or overlooking the importance of cybersecurity. 

    Rather, in many firms, it is simply not the responsibility of developers to think about the security implications of their code, because software will be passed to the security team before release.

    DevSecOps takes security and puts it on the same level as continuous integration and delivery. DevSecOps methodologies emphasize security at the very earliest stages of development and make security an important part of overall software quality.

    In essence, these approaches shift the program manager’s perspective away from making sure that software is in compliance or meets a specification or audit, to ensuring that the code is written correctly and securely and that it’s deployed in a repeatable manner.

     

    The Changing Culture of the DoD

     

    The adoption of DevSecOps methodologies is critical for DoD contractors because these methodologies reflect DoD’s own modernization strategy. Following high-profile vulnerabilities being discovered in all types of systems, DoD seems to have released that cybersecurity weaknesses are not just a potential threat to critical defense data, but also impose a significant operational bottleneck on the continuous delivery of functionality.

    At the moment, even those firms who possess a mature agile development framework can find that the multiple security checks and compliance processes that must be performed on software, prior to shipping, can detrimentally impact on their ability to deliver iterative software improvements. This is the issue that the transition to DevSecOps seeks to overcome, by attempting to shift organizations’ approach to cybersecurity away from compliance, and toward genuine security consciousness.

    At the same time, analysts are aware that shifting responsibility for cybersecurity onto developers will be uncomfortable, and potentially dangerous, for many DoD contractors. Developers working on the base code for military software do not have – and are not expected to have – an exhaustive appreciation of all of the contexts in which this will be deployed, and exactly which systems their software will be required to interface with.

     

    Automation and New Models

     

    In response to these concerns, DoD contractors are reappraising the DevSecOps model and thinking seriously about how it can be deployed in contexts where continuous service delivery is key. There are three key ways in which this is happening.

    The first is the rise of automation. The types of large-scale, multicloud infrastructures that most contemporary DoD projects rely on can often necessitate repetitive, ongoing maintenance and security assessment across both development and security teams. DevSecOps replaces these human checks with automated systems: Instead of requiring a person to go through checklists of hundreds of controls, this is done automatically as part of the software development and supply process pipeline. 

    The second key element in the transition to DevSecOps is endpoint security. The types of monolithic development processes that DoD contractors traditionally worked with are not suited to the contemporary deployment environment of many DoD projects. In these traditional methods, systems were built as discrete holes, with no expectation that data would be exposed as it moved between components. 

    This is now an obsolete approach: In DevSecOps processes, virtual private networks are used to provide security and encrypt data as it moves within a network, and the principle of least privilege reduces staff access to small portions of It environments. 

    Thirdly, a new generation of younger military and civilian personnel in the DoD, many of them trained in the commercial sector rather than entering the military directly from college, are bringing corporate approaches to the development of military software. This is seen in the exponential increase in the utilization of cloud services in DoD applications, and more dynamic and distributed managerial frameworks that distribute security responsibility across entire organizations, rather than having this as the sole remit of a dedicated security team.

     

    Get Support

     

    Moving to a truly DevSecOps methodology is likely to be a challenge for many contractors. However, just as in the last decade many firms have had to redesign their development lifecycles in order to be agile, now they will need to achieve secure development lifecycles in order to stay competitive.

    If you are looking to make this shift, you should also recognize that you are not alone. DoD is working actively with its partners in order to facilitate the roll-out of DevSecOps processes and to make commercial tools and techniques available and useful for military contractors because the department recognizes the value of this methodology for the software they commission. 

    This is seen most clearly in the recent updates to Microsoft Azure Government, though you should also be aware that many of the resources recently released by the Defense Logistics Agency are also focused on the transition to DevSecOps.

    In short, whilst the transition to DevSecOps may be challenging, it will be no more so than the earlier shift to agile development. To make this shift, however, firms should draw on the resources available to them, recognize the value of integrating security into their development workflows and build on existing agile frameworks.