Tag: devops best practices

  • Survey: DevOps Growing Pains in Salesforce Environments

    Survey: DevOps Growing Pains in Salesforce Environments

    IT organizations that have adopted software-as-a-service (SaaS) application platforms from Salesforce in part to jumpstart their digital business transformation initiatives are experiencing some DevOps growing pains.

    A survey published this week of 230 executives, managers, and members of Salesforce delivery teams conducted by Beagle Research on behalf of Copado, a DevOps platform for IT teams building custom applications, shows that while 82% have increased or maintained the size of their Salesforce development teams, the change fail rate jumped from 23% last year to 33% in 2020 when compared to a similar survey conducted a year ago. The survey also notes time to recover increased from 110 hours in 2019 to nearly 196 hours in 2020.

    Andrew Leigh, chief marketing officer for Copado, said those results generally reflect the nature of the more complex application initiatives being launched on top of Salesforce applications. The survey also noted 55% of respondents don’t consistently automate their Salesforce deployments, with less than a quarter of respondents (23%) having a way of automatically deploy a configuration from development through testing to production.

    In fact, in teams with fewer than 10 members, only 28% of survey respondents automated Salesforce deployments compared to 56% of teams with more than 100 developers that have automated their deployments, the survey found.

    The survey also noted that more than a third (34%) of respondents said features that development teams create may not be adopted. That issue suggests there is more work to done in terms of better aligning development teams with the goals of the business, Leigh said.

    Organizations building applications on top of Salesforce don’t typically embrace DevOps best practices until development teams have 25 or more members, Leigh noted. Salesforce environments generally require their own DevOps platform, because applications are constructed using a set of objects and tables unique to the platform. Those objects and tables are most often invoked using a set of low-code application development tools. Nearly three-quarters of respondents (73%) employed at least one commercial Salesforce development tool.

    Overall, the survey finds 82% of organizations have increased their budgets for or effort toward digital transformation, with 53% reporting they have exceeded their performance goals for the year. The survey also identifies a set of elite DevOps performers that are reporting 30x shorter lead times; 46x more frequent deployments; 5x lower change fail rate; and 37x shorter time to restore. Elite performing teams are 65% more likely to have adopted continuous integration than low performing teams, the survey notes.

    More than half of respondents (53%) said that they found it easy to find people who have DevOps experience in a Salesforce environment, with salaries typically in the $90,000-$140,000 range.

    The survey also finds the majority of organizations (82%) expect the systems integrators they contract to build applications to help define their DevOps processes.

    As organizations continue to adjust to new business realities in the age of COVID-19, there’s no doubt more custom applications will be built and deployed on top of SaaS application platforms such as Salesforce. The challenge is finding the best way to accelerate the development of those applications in a way that consistently produces the desired result.

  • Upcoming Event: GitLab Commit Virtual 2020

    Upcoming Event: GitLab Commit Virtual 2020

    For the first time ever, GitLab’s annual user conference will take place in a virtual environment on Aug. 26, bringing together DevOps luminaries from around the globe for a free, interactive learning experience.

    GitLab Commit Virtual is a 24-hour virtual event that provides attendees with the opportunity to join DevOps discussions, demos and presentations, and network with thought leaders from the industry’s top companies, such as Microsoft, Google, Hubspot, Forrester and many more.

    Speakers will showcase the power of community and share DevOps best practices through strategy and technology discussions, lessons learned, behind-the-scenes looks at the development life cycle and more.

    The agenda for GitLab Commit Virtual features a mix of topics, including technical sessions, live coding, deep-dives and case studies covering DevSecOps, containers, Kubernetes, CI/CD, open source, all-remote and more.

    The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions by industry leaders.

    This year’s GitLab Commit features more than 40 sessions from some of the most brilliant DevOps experts, including:

    • “DevOps Works! Why Hasn’t Security Kept Up?,” a keynote session by Joni Klippert, StackHawk.
    • “DevSecOps in Government and Highly-Regulated Industries,” a keynote session by Nicolas Chaillan, U.S. Air Force.
    • “Real World DevOps,” by Abel Wang, Microsoft.
    • “Why Your Organization Should Embrace the Community Model,” by Karl Cardenas, State Farm.
    • “Getting Fuzzy: Blurring the Lines of Traditional QA and Security Testing,” by David DeSantos and Sam Kerr, GitLab.
    • “How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab,” by Ben Allison, U.S. Army Cyber School.
    • “Measuring DevOps,” by Nathen Harvey and Dina Graves Portman, Google.
    • “How To Create an Equitable and Inclusive Culture That Transcends Physical Walls,” by Eimear Marrinan and Meaghan Williams, HubSpot.

    By visiting the expo hall, attendees will also be able to interact with sponsors, including AWS, Google Cloud, Lightstep, HashiCorp, Red Hat, VMWare Tanzu and WhiteSource.

    Attendees will get a deep dive into how enterprises are transforming DevOps at an organizational level and how they can implement similar practices in their own organization.

    To see the full agenda and to register, please visit the GitLab Commit Virtual website.

  • 6 Virtual DevOps Conferences You Can’t Afford to Miss in June 2020

    6 Virtual DevOps Conferences You Can’t Afford to Miss in June 2020

    Conferences and events make up to a trillion-dollar industry and have been playing a major role in connecting people from different parts of the world and exchange ideas. Because of the COVID-19 outbreak, the first major tech conference that got canceled due to health and safety concerns was the Mobile World Congress (MWC), the annual gathering of electronics makers.

    Along the way, similarly, Facebook also canceled all physical conferences and events through June 2021, including the major F8 Developer Conference and the most awaited Oculus Connect 7 virtual reality event that was supposed to be held in San Jose, CA.

    Even Microsoft, the giant, has announced all of its events are going digital-only until July 2021, including its flagship Microsoft Build and the prestigious Microsoft Ignite 2020.

    At the beginning of April, more than 30,000 people were expected to attend the prestigious Google Cloud Next ’20 conference, all set to happen in San Francisco. But, as the coronavirus crisis intensified all over the world, keeping the attendees’ and employees’ safety in mind, Google decided to move the entire event online.

    Today, we will see six virtual DevOps conferences you can’t afford to miss in June.

    TechStrong Con

    Date: June 4

    Cost: Free

    TechStrong Con is a virtual summit dedicated to and celebrating all things tech. The event, hosted by MediaOps, brings together some of the most prestigious industry leaders for 12 hours of immersive learning and networking. The sessions are divided into three tracks: Emerging Technologies, Security/DevSecOps and Digital Transformation. Attendees will have access to downloadable resources and will have the chance to interact with tech leaders and fellow DevOps practitioners.

    You can also be a part of the #TechStrongCon Challenge, which consists in sharing a photo of your work-from-home space during COVID-19 on LinkedIn for a chance to win either an iPad Pro or a DJI Maxic Drone.

    A portion of the proceeds raised from the event will be donated to charities dedicated to fighting COVID-19. For more information on the event and the challenge visit the TechStrong Con website.

    Agile + DevOps

    Date: June 8–11

    Free Pass: $0

    Conference Pass: $499

    All-Access Pass: $999

    The theme of the event is “accelerating software delivery with the power of Agile and DevOps.” This is an event by TechWell, and this time it is happening fully virtual. From the comfort of your own digital device, sitting at your home, or wherever you are, you will have access to all of the great content and experts the Agile + DevOps conference is known for. This time, the event will be streaming over 90+ talks—including five keynotes, 25 tutorials, more than 50 sessions and 14+ Industry Technical Presentations. All this is happening over an engaging and interactive premium virtual atmosphere. You can select the conference package that fits your needs and your budget.

    DevSecCon 24 

    Date: June 15 -16

    Cost: Free

    This virtual conference focuses mainly on the security aspect in development and operations and tackles the impact of development operations and security “run by practitioners, for practitioners.” 

    The aim here is to show attendees how DevOps and security can work together seamlessly to make continuously secure development a reality.

    This virtual expo allows for interaction with different vendors and companies. Check their website for updated details.

    swampUP

    Date: June 23-24

    Cost: $20 (all goes to charity)

    swampUP is JFrog’s annual DevOps conference, and this time it is happening in a virtual format with two full days of action-packed DevOps talks and training. The conference has a remarkable set of visionary keynotes and thought‑provoking DevOps sessions delivered by industry experts. 

    Leap into DevOps, DevSecOps and cloud-native best practices with practical training by experts delivered virtually. Sessions are experimented and thoroughly designed for developers, administrators and managers. This is regarded as one of the industry-recognized conferences of all time.

    DevOps Enterprise Summit London

    Date: June 23-25

    Cost: $240 – $480

    Gene Kim’s IT Revolution hosts this event. DevOps Enterprise Summit has great speakers and exciting courses provided by experts. It is a place for exchanging DevOps success stories and best practices. 

    Some of the big brands such as Adidas, Walmart, John Deere, Capital One and many others are participating. Attendees will get three days of immersive learning and interaction with fellow technology leaders.

    Cloud Foundry Summit

    June 24-25

    Attendee Registration: $50

    Academic Registration: $35

    Cloud Foundry Summit is where developers, architects, operators, CIOs and other IT professionals meet to share the best software and IT practices and innovate together. Simplifying developer experience is the theme of the conference where both days are filled with interesting sessions and hands-on labs. 

    This is where you will learn how to automate, scale, and manage cloud apps throughout their lifecycle. 

    It looks like virtual is the new normal for the events industry and for the companies looking to host future events. The upsides of the virtual format of the conferences are many: It is easy to attend, saves a lot of money we used to spend on travel, stay, food, etc. and eliminates the effort and fatigue that used to happen while attending a physical conference happening in some other city or country. Well, thinking positively about any situation makes you feel good, and I hope we will get out of this COVID pandemic as soon as possible.

  • Scaling DevOps for the Enterprise

    Scaling DevOps for the Enterprise

    Information technology has been an integral piece of the modern enterprise for multiple decades and that dependency is only growing. With digital transformation, there’s the inevitable increase in demand for new applications. As such, software development services will continue to be a vital component of the business amidst the mounting pressure to innovate and deliver. This has resulted in many organizations moving from traditional development practices to more flexible and agile methodologies. Conventional software delivery methods are also being replaced in favor of enterprise DevOps practices such as continuous integration (CI) and continuous delivery (CD).

    While DevOps stimulates innovation and speeds up software delivery, adopting DevOps practices does not guarantee success as there are times when companies have been underwhelmed after implementing DevOps practices across their development teams. Knowing this, it is important to state that most DevOps failures come down to flaws in the execution of the methodology. A best-practice DevOps implementation should increase the value and impact of IT infrastructure by bridging new and old technologies. This allows for companies to better navigate change with clear time-to-value merits and lower risk. In short, it’s about scaling DevOps practices with security and quality embedded every step of the way.

    Look for Small Wins and Build on What Works

    Implementing DevOps best practices can mean a radical shift from the way an organization currently works. It is important that the entire team buys into this new approach. However, different dynamics within different organizations can lead to different results.

    Ideally, you should never have large complex projects. The best approach would be to work in small batches where you and your team can quickly learn from your decisions. By identifying the bottlenecks causing the largest constraints in your delivery process and incrementally changing, transforming and optimizing, your team could demonstrate the advantages of the new DevOps practices and build confidence in the team’s ability to implement the new methodology. Wins like these give a great start to the project before you’ve even introduced the entire IT organization to the changes needed to implement DevOps best practices. 

    Break Down Organizational Silos

    Known as well-intentioned areas of specialization, organizational silos are defined within the business to sharpen expertise and assign roles. Silos may have unintended consequences over time though, as each department potentially starts paying less and less attention to the other departments as they become consumed by their own assignments. As a result, silos inadvertently limit collaboration and have the potential to contribute to delays, bugs and conflicts. This is why C-level executives must initiate the process of removing the barriers to these silos and integrating the different disciplines within the IT department.

    For DevOps to work across the enterprise, executives must reorganize the configuration of software development projects by bringing in representatives from all important IT disciplines.

    Everyone Needs to Be on the Same Page

    Sometimes silos can be deeply rooted in an organization, and even if you do succeed in removing the barriers, there’s always the risk that they could re-emerge. Due to this, it’s important to create motivation for a silo-less enterprise.

    Anyone wanting to change a culture needs to define the actions and behaviors they desire, and design the work processes that are required to reinforce those behaviors. If your ops team is measured only by mitigating risk and your dev team is measured by delivering change, it goes without saying that you have a conflict.

    Through the incorporation of intra- and inter-team collaboration metrics into individual and team performance reviews, you can base a considerable amount of the review on lead times and quality metrics for software delivery. This is important not just for the dev and ops teams, but also QA and security. It’s easier to act your way to a new way of thinking rather than think your way to a new way of acting. 

    Real-Time Visibility Across the Toolchain and Environments

    When a team has poor visibility of their system, it can result in bad decisions and missed opportunities. Teams must replace manual project and release tracking methods that use spreadsheets and emails with an open, web-based solution that your team can leverage to plan, track and govern the entire application release management process.

    As teams and their stakeholders need real-time visibility across the entire DevOps toolchain and production environments, it is important that the chosen solution enables product team members to focus on their critical tasks while providing pertinent real-time information to their managers and stakeholders. 

    Don’t Lose Sight of the End User

    Once deployed, the application or service will interact with existing, and quite often, new systems. As it is developed for use by humans, don’t lose sight of the end user. Their satisfaction determines the success of your application or service.

    Actively involve users every step of the way, not just at the ideation and product requirements level. Teams should take the appropriate time to properly assess and fully understand the issues, challenges, priorities and constraints of their users. This knowledge can be utilized to define key performance indicators (KPIs) and continuous feedback throughout the DevOps toolchain.

    Move Forward on Orchestrating Continuous Delivery

    There’s no question that a lot of work goes into preparing and deploying a release. With the goal of delivering releases that have a high impact, it seems that companies sometimes choose to hold and then bundle together multiple application improvements into a single release. Such a strategy can lead to poor quality and failure—a result of deploying large infrequent releases. As another key driver toward an increased need for orchestration and automation, a lack of skilled employees means that many organizations have trouble releasing software in a reliable manner.

    The orchestration of continuous delivery is a fairly new way of planning and delivering business applications across the enterprise. With a focus on continuous improvement, continuous integration and ensuring you are always ready to deliver what the business needs, release control and deployment automation are vital to ensuring smooth delivery and a basis for governance.

    Conclusion

    The implementation of DevOps is a long term commitment. More a philosophy directing how you work, DevOps is not a rigid set of practices like ITIL, lean or Agile development.

    No organization will reach a state where it can comfortably say it has perfected its DevOps best practices model. Instead, it must continuously experiment with new processes, capabilities and tools identifying those that can yield the highest possible integration across the entire DevOps toolchain to deliver the best value for the business.

    — Mark Levy

  • Top 3 Challenges of DevOps Adoption

    Top 3 Challenges of DevOps Adoption

    Customer expectations continue to relentlessly rise as new technological opportunities emerge. Today, organizations demand products and application features are delivered and implemented wherever and whenever needed. Everywhere you look, execution is at risk of falling behind imaginations and business imperatives. That is, of course, unless DevOps is starting to wield a strategic and philosophic influence.

    DevOps has been one of the hottest enterprise trends for some time now, and a crucial concept in helping companies satisfy customer demands by bringing teams together to fuel better collaboration and innovation.

    According to Deloitte, organizations adopting DevOps see an 18% to 21% reduction in time to market.

    By removing the waste that impedes software development, operations are streamlined, and businesses can react faster to market demands. At the same time, automation enables companies to align business objectives with processes to immediately recover from IT failures. Deloitte also reports the speedy, DevOps-influenced, customer-friendly release of new products and services led to a 20% revenue increase.

    While that is all good, DevOps is still a new topic to many. Large scale adoption is generally slow. It is important to note DevOps is not simply the implementation of new tools. It is about rebooting deep-rooted cultural habits, transforming old processes and ensuring all changes are made for the right reasons. Don’t embrace DevOps for the sake of it. Only proceed if you have clarity and purpose.

    Breaking of the Deep-Rooted, Cultural Habits

    DevOps is not a team. It is a culture of collaboration that yields a set of best practices and operational cultures. Sometimes companies wanting to adopt a DevOps approach are met with resistance from employees uncomfortable with change. Leadership needs to come from the top. Executives must support employees in dismantling the status quo and breaking down silos hindering successful implementation. Motivation rises when results are positive, concrete and observable. There is no magic formula but, if you get the right leadership and culture in place, chances are DevOps will land with resonance. Gartner reports 88% of businesses believe team culture is one of the top impacts on an organization’s ability to scale DevOps.

    Changing Well Defined Processes to More Efficient Ones

    The best way to identify inefficiencies is to map processes and recognize what is and isn’t working. Start by looking for waste–areas where resources are being exhausted without delivering real value. A silo-influenced lack of communication can significantly slow down businesses and there is a risk each department will think DevOps is not their responsibility. Some may be resistant to implementing change, which will cause unnecessary lags within the business. It is vital to understand it is not just the responsibility of software developers to ensure the processes work for them. DevOps is a process that brings development teams and other IT stakeholders together to achieve one common goal: delivering faster, higher quality work to market.

    Beware of DevOps for DevOps Sake

    With DevOps, companies can streamline and automate every task. That doesn’t mean it’s right for every element of every business. Often, companies will pick a couple of departments to trial a DevOps approach with–usually the development team. The temptation is then to continue scaling across the organization as soon as positive results are apparent. The issue here is that different departments all have different needs and challenges and, as we’ve already said, effective DevOps rollout requires an overhaul of processes and ways of working. Organizations need to be careful and think about specific business needs, instead of just being engaged in a rudderless trend chase. Know your objectives before engaging in sweeping overhauls. Keep learning and, above all, stay tuned to customer needs.

    — Rodrigo Albuquerque

  • How DevOps Can Help Speed Go to Market

    How DevOps Can Help Speed Go to Market

    With continuous evolution of IT systems, speed and flexibility have become of paramount importance for businesses. This requirement has caused a massive shift in the IT delivery system. Now, building and releasing a better product in the market is not enough for businesses to stay ahead of the competition. Organizations need an agile approach to understand and adapt to information, trends and new developments, and to meet the demands of time-to-market features.

    DevOps is one such cultural shift in the IT field that shows how software development and IT operations can work together to reduce time to market. It has attained such a great profile in the market that people have started measuring the outcomes for businesses that adopt it.

    If you’re just beginning with DevOps, here are some tips that will help you understand how you can accelerate time to market for your product and services.

    How Can DevOps Accelerate Time to Market?

    There are many ways in which DevOps helps organizations accelerate time to market for their product. Some of the most effective ways are:

    Faster Delivery of Features and Modifications

    When development teams build software, they connect with IT operations to send the software for testing. If the product is completely new, operations need to create a testing environment. If the software is an updated version of the current product and there is already a testing environment for it, operations still need to configure and add interfaces and side applications. So, a developer can only deploy code to the software when the operations team tests the product, which is a very time-consuming process.

    However, DevOps eliminates such time-consuming tasks from the software development process. For example, with automated testing of web apps developers get quick feedback and automated integration allows them to make changes in the code base more quickly. Therefore, organizations can release small or incremental updates of the software while delivering new features to market faster.

    Enhance Efficiency

    DevOps encourages development teams to give more time to value-creating work. When businesses use automated testing and integration, developers don’t have to waste their time waiting for machine configuration or code integration. Both tasks can be achieved by clicking a button on the self-service portal.

    For example, many European banks have implemented DevOps in their software process, which resulted in 25% efficiency improvements in providing updates for their online banking applications. It also reduces the workload for the IT operations team so that they can work on more challenging tasks to add more value to the company.

    Improved Quality Code and Quick Recovery from Failures

    When software is released to the market, developers often start working on their next project. So, they usually don’t have any motive to predict or prevent future problems related to software; it’s all up to the operations team. But DevOps keeps developers involved during the entire life cycle of a software product for updating any feature or application, which results in improved quality code. Also, it requires only a few fixes as developers can track and eliminate potential problems while writing code.

    As developers work with smaller chunks of code, when a failure occurs in any product, bugs can be tracked easily to their resources. Also, human errors are reduced thanks to the automation that DevOps provides to the software life cycle, while allowing companies to deliver fixes faster.

    Best Practices for Using DevOps

    Just like agile approaches, DevOps doesn’t have any pre-planned implementation model. But, most companies that use DevOps follow these best practices:

    Set a Business Standard

    The improvements in an organization can never be measured without having a business standard. If you want to reduce time to market for your software development process, then have a look at the current development process and find out which areas need improvement. For example, you can review the steps involved in making a project live and identify any defects, inefficiencies and constraints in the project.

    After reviewing these processes, you can set a business standard that shows the current software development process and the improvements that are required to reduce the time to market. With DevOps, you can set a business standard more quickly and improve your software deployment process.

    Optimize and Eliminate Unnecessary Inputs

    While reviewing your software deployment process, you might encounter some inputs that don’t add value to the process and reduce its speed. Eliminating such inputs from the development process is crucial, but make sure there is open communication between you and your team so efforts are not wasted.

    What you can do is set up the right team structure and use tools that provide transparent and fast communication between the teams. For example, you can structure a team that includes marketing managers, right analysts and, most importantly, DevOps resources.

    Allow Continuous Deployment in Software Process

    Continuous deployment is one of the essential key factors of DevOps that helps in reducing time to market. It is the continuous delivery pipeline that doesn’t involve any manual intervention in-between. In continuous deployment, automation stimulates and simplifies communication and validates the software process to ensure timely releases.

    However, not every company implements continuous deployment in its software development process. Usually, the organizations that need to move faster to provide new features, applications or security channels for their product use continuous deployment. For example, media companies and online retailers use continuous deployment in their software development process.

    Improve the Quality of Automated Tests

    One straightway to reduce time to market with DevOps is improving the quality of automated tests. In any organization, testers test the application for its functionality and other factors. But this testing process can be enhanced by engaging with clients and a targeted audience in the development process. Taking input on the overall functionality and user interface will not only improve the testing process, but also help you find bugs and defects earlier.

    It is proven that if bugs are not tracked and eliminated in the early stages, it can greatly impact the time to market for your software product. For example, if you want to test your web application browser compatibility, then consider cross-browser compatibility testing. With end-to-end automated testing, the overall testing process can be improved, which will result in reducing time to market. Some other benefits of automated testing that can improve your DevOps are:

    • Track and eliminate bugs and errors in the early stages to improve the system’s capacity.
    • Improve the security of your software product.
    • Enhance custom engagement and satisfaction with a high QoE score.
    • Less cost of ownership.
    • Meet the industry standards and compliance regulations in a better way.

    An improved automation strategy helps move your product to market faster and allows your resources to do more high-value tasks. Also, the development teams will be more encouraged and confident to add new features to the application, as it will be tested more thoroughly.

    Conclusion

    Today’s businesses heavily rely on applications to collaborate, communicate, complete sales and operate more proficiently. Therefore, they strive to bring these applications to market more quickly so they don’t miss any opportunities and easily adjust to the market standards. To achieve these objectives, organizations must adopt the right DevOps practices in their software development processes to reduce time to market.

    — Junaid Ahmed

  • 7 Ways to Introduce DevOps in Your Work Culture

    7 Ways to Introduce DevOps in Your Work Culture

    As many industries are going through a wave of digital transformation, a number of key technologies and principles are being deployed to business advantage. One such principle is DevOps.

    This collaborative principle is proving to be extremely helpful for businesses in their pursuit of customer satisfaction and beating their competition.

    The DevOps trend is growing, as cloud providers including AWS, Azure and Google Cloud are moving faster in upgrading their DevOps services and tools to address business needs.

    According to a Google Cloud and Harvard Business Review Analytic Services report, “two-third of companies that use DevOps have seen benefits impacting their bottom line, including productivity (67 percent), increased speed to market (70 percent), innovation (66 percent), customer relevance (67 percent) and product/service quality (64 percent).”

    While most companies are already reaping the benefits of DevOps practices, some organizations are still doing their homework. Here are seven tips to help you understand how your organization can use DevOps to its advantage:

    Begin with a Small Project

    It’s always best to start with a small project before you start engaging DevOps practices on a large scale. A pilot project will enable you to understand the core capabilities of the DevOps process and how you can map them to your business objectives.

    Utilizing Open Source Tools

    Using open source tools will keep you in touch with current trends and practices. Open source tools are easily available and easy to integrate. You can use these to enhance your DevOps experimentation.

    Introducing Security

    The DevOps process faces a threat in terms of security, which can be disruptive to an organization’s reputation. Hence, it is advisable for organizations to introduce security at the early stages of the DevOps process. Additionally, it saves a lot of time and resources, which are very crucial aspects of the DevOps process. The concept of DevSecOps is a wiser approach as it includes security all through the software development lifecycle (SDLC) process.

    Make the Most of DevOps Best Practices

    Looking for a process that drastically improves productivity and reduces time to market? DevOps best practices are designed to increase the pace of software development. With practices spanning site reliability engineering (SRE), end-to-end automation, continuous integration, testing and delivery, proactive monitoring and more, your team will be able to utilize their time effectively and devote their attention to other important business-driving processes.

    Enhance Team Skills

    The key to bringing out effective production results is having a skilled team that is equipped with the necessary training. Therefore, it is essential for organizations to provide their employees with a proper understanding of the organization goals in general and the processes employees are part of. According to the report, three-quarters of the best DevOps teams said they provide hands-on learning experiences with code labs and projects exercises.

    Avoid the Blame Game

    DevOps aims to bring about an increased pace of operations and fast learning, among employees. But most of the time for any new process to fall in place, individuals involved have to experience failure. And with the failure of the first project often comes the blame game. However, organizations need to understand that failure is the initial step to achieving future success. Moreover, firms should adopt the policy of “fail and adjust sooner.” The experience of learning from mistakes will take you farther along in your DevOps journey.

    A DevOps-Friendly Environment

    A DevOps-supportive culture is incomplete without the above exercises. Hence, it is essential that organizations bring about an environment that provides room for shared goals, improved transparency and making growth-driven decisions.

    So, industry change-makers: Are you ready for your DevOps experience?

    — Veritis

  • 9 Pillars of Continuous Security Best Practices

    9 Pillars of Continuous Security Best Practices

    Without proper consideration given to security best practices, the continuous delivery of software changes facilitated by DevOps is risky. On the other hand, DevOps provides an opportunity to reduce security risks if security is integrated into the continuous delivery pipeline according to best practices.

    This blog enumerates best practices for security across nine pillars of DevOps: Leadership, Collaborative Culture, Design for DevOps, Continuous Integration, Continuous Testing, Continuous Monitoring, Elastic Infrastructure, Continuous Delivery/Deployment and Continuous Security. Examples of best practices for each pillar are listed. These practices can be used to assess an organization’s maturity within the journey to Continuous Security, often referred to as DevSecOps.

    Leadership

    Leaders need to understand and sponsor a clear vision for security.

    • Leadership demonstrates a vision for organizational direction, team direction and three-year horizon including security practices.
    • Leaders intellectually stimulate the team status quo by encouraging asking new questions and question the basic assumptions about the work including security practices.
    • Leaders promote personal recognition by commending teams for better-than-average work, acknowledging improvements in the quality of work and personally compliment individuals’ outstanding work including security practices.

    Collaborative Culture

    Culture in organizations that work well with DevOps have a collaborative continuous security mindset.

    • The culture encourages cross-functional collaboration, shared responsibilities and avoids silos between developers, operations, project management, quality assurance and security.
    • The DevOps system (toolchain) is created by an expert team and reviewed by a coalition of stakeholders including security.
    • Changes to end-to-end DevOps workflows are led by an expert team and reviewed by a coalition of stakeholders including security.
    • DevOps culture empowers and trains team members to take personal responsibility for security, compliance and privacy obligations.
    • Security engineers/architects are involved in the design for modular components, and also consulted when security patterns change within modules.

    Design for DevOps

    Designing software for DevOps at speed requires application designers to master the best practices for continuous security.

    • Software source code changes are pre-checked with static analysis tools, prior to commit to the integration branch. This assures that the modified source code does not introduce critical software faults and security vulnerabilities such as memory leaks, uninitialized variables, array-boundary problems and SQL injection.
    • Software component analysis scans third-party components for known security vulnerabilities and identifies risk during the build process.
    • Security frameworks for technology stacks that are used (such as Apache Shiro or Spring Security) are documented and shared with developers for their respective technology stacks.
    • Software code changes peer code reviews include checks for defensive coding and security vulnerabilities prior to committing code to the integration/trunk branch.
    • Common security components such as identity, authorization, key management, audit/log, cryptography, protocols, etc. are maintained, published, readily available and used within module development.

    Continuous Integration

    Continuous integration (CI) within organizations that have multiple teams working concurrently on a project and different code bases is challenging. During the integration stage it is critical to assess the application and understand the impact of code changes from a security point of view.

    • A software version management system is used to manage versions of all changes to source code, executable images and tools used to create and test the software.
    • Incremental static analysis pre-commit and commit checks are wired into CI to catch common mistakes and anti-patterns quickly by only scanning the code that was changed. These checks identify security vulnerabilities through control flow and data flow analysis, pattern analysis and other techniques. These techniques find security-related issues such as mistakes in using crypto functions, configuration errors and potential injection vulnerabilities.
    • Binary artifacts are digitally signed and stored in secure repositories.
    • Changes to security patterns used within software source such as session management, authentication, authorization and encryption code trigger a notification or pull request to security engineers.

    Continuous Testing

    Continuous testing (CT) with DevOps has significant advantages for continuous security when best practices are followed.

    • New security tests that are necessary to test a software change are created together with the code and integrated into the trunk branch at the same time the code is. The new tests are then used to test the code after integration.
    • Security tests for each DevOps pipeline stage are automated and may be selected automatically according predefined criteria.
    • Release regression tests include security tests. At least 85 percent of the security regression tests are fully automated and the remaining are auto-assisted if portions must be performed manually.
    • Test results that indicate possible security concerns are tagged for security analysis.
    • Dynamic or interactive application security tests exercise the application for security vulnerabilities. Results of these tests are delivered to developers through tools and feedback loops native to their organization.
    • If containers are used, image repositories are scanned for images with known vulnerabilities, hash checks for image drifts and run-time checks for vulnerabilities during image deploys.
    • Attack patterns, abuse cases and tests are built for application module profiles.
    • Unit, functional and integration tests around—and especially outside—boundary conditions are run during CT. Tests include error handling, exception handling logic and negative tests.
    • Automated security attack testing to include the OWASP Top 10 in integrated into automated testing.

    Continuous Monitoring

    Continuous monitoring (CM) of security considers the dynamic nature of artifacts and infrastructure and a proliferation of objects and services to secure.

    • Metrics and thresholds are automatically gathered, calculated and made visible to anyone on the team that subscribes to them. Example security metrics include:
      • Number of security defects identified pre-production
      • Percent of code coverage from security testing
      • Number of failed builds due to security checks
      • Mean time to detection
      • Mean time to resolution
    • Vulnerability information in consolidated to provide a comprehensive view into vulnerability risks and remediation across tools, pipelines and apps—and over time.
    • Metrics and events from production security controls such as WAF, RASP, etc., are used to improve security testing.
    • Insight into security threats and events are shared and visible across DevOps teams to enable “attack-driven defense” methodologies.

    Continuous Security

    Continuous security (CS) is itself a distinct pillar with standalone best practices that cross all of the other pillars.

    • All information security platforms that are in use expose full functionality via APIs.
    • Immutable infrastructure mindsets are adopted to ensure production systems are locked down.
    • Security controls are automated so as not to impede DevOps agility.
    • Security tools are integrated into the CI/CD pipeline.
    • Source code for key intellectual property on build or test machines are only accessible by trusted users with credentials. Build and test scripts do not contain credentials to any system that has intellectual property.
    • External penetration tests (done out of band) are scheduled either periodically or on a regular cadence are used to perform deep-dive analysis.
    • Telemetry from production security controls such as WAF and RASP are delivered back to development teams to inform application updates.
    • Accurate inventory of all software packages and version information is documented via infrastructure as code. Automated detection is used to identify whether any of the packages have known CVEs associated and define specific remediation actions.

    Elastic Infrastructure

    Elastic infrastructure environments offer advantages compared to legacy or traditional static infrastructure. However, elastic infrastructures need to follow best practices for continuous security because flexible infrastructures offer a broader range of attack surfaces.

    • Configuration code includes automated checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Development tools are not installed on production.
    • Security-approved OS, software versions and frameworks are used to compose required infrastructure. Security-related controls such as ACLs and FIM are defined as a part of infrastructure where applicable.
    • A least-privilege model is enforced for processes running on shared infrastructure.
    • Smaller clusters are used to reduce complexity between teams.
    • Service provider partners security controls are validated to ensure they meet business requirements in their domains of the shared security model.
    • IaaS or PaaS service provider security controls are validated to ensure that they meet business requirements in their domains of the shared security model.

    Continuous Delivery/Deployment

    While DevOps enables new feature deliveries to users quickly, to minimize risk during deployment the following best practices are important:

    • Release-to-production decisions are determined according to predetermined metrics, which include security metrics.
    • A whitelist policy for application segmentation is enforced during deployment for each environment, especially production.
    • Continuous deployment processes trigger run-time security and compliance checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Verify development tools are not installed on production.
    • All secrets used for deployment are vaulted and retrieved programmatically during run-time or initialization of the continuous delivery process.

    In this article we detailed best practices for nine pillars of continuous security, otherwise known as DevSecOps. While is it clear that DevOps offers immense value for software deployment, the adherence to best practices is essential to reduce risk and assure security. Each organization is different and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization.

    Aggregation of end-to-end security metrics, from planning through to operations, is important but beyond the scope of this blog. End-to-end security monitoring tools, such as value stream management applied to DevSecOps and enterprise security dashboards, is a topic that we intend to cover in a subsequent blog.

    This article was co-authored by Imran Chaudhari. Imran is a principal security consultant at Trace3, where he assists clients in assessing and designing cybersecurity initiatives from a strategic, organizational, and technical perspective. His experience covers expertise in secure software development, application and cloud security, as well as identity and access management and DevSecOps assessments.

    — Marc Hornbeek

  • Be Here Now – Agile and DevOps in the Current State of Synergy

    Be Here Now – Agile and DevOps in the Current State of Synergy

    If there’s one thing that our culture does not lack, it’s a litany of pithy catch-quotes meant to remind us to focus on the task at hand; yet, this often runs counter to our tendency to fixate on matters of the past and future.

    While we are so often encouraged to “live in the moment” and “seize the day”, this is hardly an easy task, especially as related to any sort of emerging phenomenon that compels us to improve on historical missteps, and predict how things should change for the better.

    Register today for the 3rd Annual DevOps Virtual Summit.

    With the methodologies of agile and DevOps the tendency is, of course, to do the same, harping on the inefficiencies of previous software delivery models and painting an elaborate portrait of how related workflows are being transformed overnight.

    The simple truth is that it’s easy to get excited about concepts that hold such tremendous potential in recasting an increasingly critical vital set of processes, and lose track of where things actually stand.

    To note, while a recent research project published by Coleman Parkes found that over 80 percent of organizations have adopted some manner of agile and DevOps practices, and see them as critical in transforming their internal software factories, only a third have adopted the methods on a broad scale.

    Point being, we’re still pretty early.

    That said, we in the business of helping organizations adopt related culture and tooling have gone to great lengths to encourage everyone that this change should be pursued with dogged intensity. We have sliced and diced the data to illustrate how those organizations at the forefront of so-called digital transformation, enabled by agile and DevOps, are realizing the results in the form of increased velocity.

    The same research finds that “advanced” adopters of the two concepts are, in fact, seeing significant improvement in time-to-market, customer satisfaction and new business growth.

    But research is just that, and often not completely aligned with real-world scenarios. Someone who takes the time to answer a survey about such matters, one could reasonably expect, is the type of person far more likely to be involved in agile and DevOps activities.

    My personal conversations with everyday practitioners [aka other parents on the sidelines at my kids’ sports and social events, many of whom work in IT] tell me that we’re much more oriented to the “pockets of innovation” phase at present, than any sense of pervasive adoption.

    So this begs the two-part question – where do we really stand, and what do I really need to care about?

    The only reliable source of record in my mind is the perspective of people already doing the work, beyond what I can discern amid basketball games and middle school theater. Real-world practitioners are the voices of reason that allow us to “be here now” and address the specifics of practical agile and DevOps implementation.

    Over the past several years, I’ve found one of the best sources of such input to be the customer panels available at industry conferences and on webcasts. When it’s time for me to sit down and crank out some related content, I often go back to these recordings to remind myself where the rubber actually hits the road.

    On Tuesday Mar. 7, we’ll host just such an event, the 3rd Annual DevOps Virtual Summit, where agile and DevOps leaders from organizations including CNN, GM Financial and United Airlines will share their thoughts on how this ongoing transformation is playing out, and where the remaining challenges lie.

    Along with those experts, we’ll also hear from Dr. Nicole Forsgren, one of the leading researchers in the space who is in seemingly constant contact with people leading the charge and working in the trenches putting agile and DevOps into practice.

    As a marketer, and previously as a journalist, everything that I know comes from direct interaction with those colleagues willing to share their hands-on experience garnered via doing this work every day.

    Register for the event and join us to find out where agile and DevOps actually stand today.

    — Matt Hines

  • 28 DevOps and Continuous Delivery Reference Architectures (Vol. 2)

    28 DevOps and Continuous Delivery Reference Architectures (Vol. 2)

    People want to get going with DevOps or Continuous Delivery, but need a place to start.  Others are already on their way, but need some validation of their choices.  In April, I published the first volume of DevOps and Continuous Delivery reference architectures which has now been viewed over 37,000 times on SlideShare (it’s free to download…no registration required).  Three things helped people in the deck: (1) the reference architectures, (2) links to the sources for each architecture attached to each slide, and (3) no marketing fluff.

    [slideshare id=45996806&doc=nexusandcontinuousdelivery-150318110625-conversion-gate01]

    I am honored to have helped so many people on their DevOps and Continuous Delivery journeys.  So this month, I compiled Volume 2 of the reference architectures.  You can now view the deck on SlideShare, download it (again…no registration required), and share it with others.  Have a look and let me know what you think.

    As I did with Volume 1, if you have a reference architecture that you would like to share, I would be happy to add it into Volume 2 with full attribution to you.  Just ping me in the comments section or reach out to me @weekstweets.

    Here is Volume 2:

    [slideshare id=50972100&doc=devopscontinuousdeliveryreferencearchitecturespart2-150727141843-lva1-app6891]