devopsy.kinsta.cloud

Tag: benchmarks

  • 7 Highly Effective Continuous Delivery Principles

    7 Highly Effective Continuous Delivery Principles

    If you’re in the IT space and you weren’t born yesterday, then you understand the need for speed. Development and release cycles are now faster than ever as companies implement continuous integration and continuous delivery (CD). Browsers and social media sites, for example, are doing multiple releases a day, and organizations that want to keep up in the information age are implementing continuous delivery. But to ensure successful continuous delivery, there are continuous delivery principles every organization should know.

    Here are seven continuous delivery principles that make highly effective and efficient development and release cycles:

    1. Automate, Automate, Automate. While more and more organizations are recognizing the need to automate their end-to-end release processes and delivery, it can still be a burden if not done correctly. For example, some still refrain from automating unit tests, but this actually slows them down in the long run, especially when human error inevitably comes into play.
    2. Always Be Testing. Obviously, if you want faster and better release cycles, then you need to test constantly. As mentioned, automated testing is a key to continuous delivery, and you don’t want a bottleneck between QA and development clogging up your process.
    3. Small Releases. One of the core continuous delivery principles is that smaller and multiple releases are usually better than one large one. It’s more efficient—and even safe—to keep releasing a few changes then waiting to add a large batch of features and bug fixes before you deliver. Then, if any revisions need to made, it will be easier to make them without affecting the other features.
    4. Use Benchmarks. Adding an automated benchmark suite to your builds will help you optimize your performance by preventing any regressions, which is important if you want a successful continuous delivery.
    5. Use Source Control. Integral to continuous delivery is making sure you can keep adding versions without affecting existing components and features. This not only backs up your SQL code, but also allows for continuous integration and, thus, continuous delivery.
    6. Code Reviews. Many organizations use a hierarchal system for their reviews, which means more and more senior developers have to review the code before it’s approved. A peer-based system in which developers review each other leads to a faster and more efficient process.
    7. Pull Requests. Using a pull request can speed the process significantly. When others can review the author’s code simultaneously as well as suggest modifications before it’s integrated into the master, there will be better communication and fewer bottlenecks.

    Continuous delivery is a not just a great idea, but quickly becoming a must-have, as anyone who uses the agile method will tell you. It’s important, however, that whether you’re introducing this into your organization or looking to optimize your continuous delivery methods, you use the right continuous delivery principles to keep your organization fast and efficient.

    About the Author / Yaniv Yehuda

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

  • A DevOps Checklist for Traditional Service Providers

    A DevOps Checklist for Traditional Service Providers

    As companies such as Amazon and Google rapidly innovate to deliver new services, traditional service providers recognize that change is necessary to keep up with shifting customer expectations. Given the pace at which technology continues to morph, creating better, faster and more innovative solutions is a necessity, and if this isn’t achieved, even longtime customers will eventually look elsewhere.

    For younger businesses, taking a collaborative approach to IT and product development often comes naturally as it’s built into the company’s DNA. However, for more established service providers, adapting to this new way of doing business can prove challenging. Traditional service providers have spent years perfecting their technology and require multiple layers of review prior to rollout. While these checks and balances are in place to ensure a level of quality customers have relied on for years and expect to receive from traditional providers, it also can hinder their ability to react quickly to client demands. However, the adoption of the principles embedded in DevOps can allow traditional service providers to work more like a startup by accessing their technology and human skills in a new way, while also continuing to deliver products which meet the expectations of their established customers.

    Now the question is, how can traditional services providers successfully implement this DevOps approach? While it can (and has been) done successfully, there are five critical steps that need to be taken into account:

    1) Establish a clear goal. The most important step is the first: Management must have a clear understanding of what they are looking to accomplish with the DevOps transition. Service providers have a long legacy of well-defined, reliable services, so all changes must complement their current product offerings and live up to the quality their customer base has come to expect. If an overall goal is not defined, customers will be left confused and disappointed, and ultimately, there will be no impact on the bottom line.

    2) Set a timeline. While creating an unrealistic timeline is never advised, it is critical to set an aggressive, pragmatic and adjustable one. As mentioned above, without aggressively pushing forward, an organization will find itself continuously playing catch up to its competitors. The timeline is meant to push an initiative forward even when there are setbacks or changes that need to be made along the way. The right timing is a balancing act: too fast and you have a poorly crafted product rollout; too slow and you are stuck behind the competition. The key metric to measure progress is the degree of evolution to the DevOps model within key stakeholder organizations. If solutions are delayed due to existing processes, then either the scope of the team needs to be adjusted to encompass those processes or the goal needs to be changed so they are no longer an issue.

    3) Collect necessary resources. Typically, the biggest gap that needs to be filled to move forward is with human resources. For many established companies, having design and architecture skills—core capabilities needed to develop a new product—hasn’t been a priority. Creating the right team that consists of new talent that have these missing skills, along with the addition of current employees who have a more intimate understanding of the company and customer, is a critical aspect in making sure this more collaborative and innovative approach to solution development and delivery works. And it doesn’t stop once the team is created, it is important to continue to foster an environment that encourages the new team to work together and promote their process within the broader organization.

    4) Create benchmarks. To ensure the established timeline is being met and that there is an opportunity to change course if necessary, it is important to set clear deliverables at various stages of the process. These benchmarks must look to what people are doing today, not just the end goal. Initial measures should focus on the pace at which progress is being made, and later, focus on the end products being delivered.

    5) Get the entire company on board. Changing an embedded philosophy isn’t easy, especially one that has worked well for so long. No matter the organization there is almost always resistance on some level when fundamental changes are being made. It is up to leadership and the DevOps team(s) to demonstrate internally and externally that the changes being made are not just for the sake of change, but in the end will benefit the entire company, as well as the customer.

    While taking a deeper look at an organization’s “people, process, technology and information” and moving to a new mindset doesn’t happen overnight or come without its hiccups, the status quo is no longer sufficient to compete. The reality is, a more collaborative and faster delivery model is necessary to be successful in tomorrow’s marketplace.

    About the Author / Tim Pearson

    timpearsonTim Pearson is the director of product line management at Ciena. In his role, Tim leverages DevOps practices to break barriers in network delivery to meet the demands of mobile, VR and video applications.  Driven by challenge and fueled by deep industry knowledge, he has built a reputation for developing innovative business and product strategies to drive growth and open new markets. Tim holds a Bachelor degree in Electrical Engineering from Memorial University, a Masters degree in Management Science from the University of Waterloo and an MBA from the MIT Sloan School of Management. Connect with him on LinkedIn and Twitter.

  • The Big DevOps Question: How Do We Get Started?

    The Big DevOps Question: How Do We Get Started?

    Every conversation I have with clients regarding DevOps eventually reaches a point where the client wants to know my recommendations for getting started with a DevOps program. Some have already embarked on a DevOps program, but want me to critique their approach against what I see others doing. Others simply don’t have a clue how to make the necessary changes in their organization.

    Ultimately, I sense in all these conversations a lack of confidence that their intended outcome is achievable and that they’re on the right path.

    The first questions I ask clients are, “What are you looking to accomplish, and what are your business drivers?” Interestingly, 90 percent of the time clients are unclear why they want to embark on this journey. Sure, DevOps makes sense academically, but if you don’t have a clear understanding of your expectations for improvement most likely you’ll end up with more questions.

    Sometimes it helps if I give prompts:

    • Are you looking to improve quality in your production releases?
    • Do you need to release updates and patches into production more quickly?
    • What metrics are you currently looking at, and what makes you believe these are not optimal for your business?

    This last question is really important. Quite often data represents invalid perspectives. Other industries’ and services’ metric of how often they deploy to production or how long it takes execute a release cycle might not be right for your business or industry. I hope medical device and airplane equipment manufacturers take a lot longer to bring something to production and test it more robustly than Netflix does its website.

    In an earlier post I wrote that the need for DevOps is effectively the admittance of a problem; to wit, the cure is continuous delivery. Hence, I often tell clients that a very realistic place to start is not with the actual work, but with the communications methods and pathways that will affect implementing continuous delivery within the organization.

    So many clients want to start their DevOps journey in application development and talk about what they’ve done with continuous build. That’s fantastic, but it has more to do with Agile software development than it does DevOps. If all that work creates bottlenecks in testing, you’ve accomplished very little. Now you must fix the flow to balance out development and testing. Trying to achieve continuous development through serial analysis and correction will take a long time and show little progress along the way—and often leads to abandonment.

    However, if all the leaders of all the various areas involved in the continuous delivery cycle discuss how their efforts are impacted by what the other leaders’ groups do, everyone can see the bottlenecks and constraints and they can prioritize changes. Management often fosters much of the cultural impairment, as these changes can impact everything from workload to bonuses. Getting everyone involved in working together to eliminate the bottlenecks often buys credibility for the program and minimizes some of the individual adoption issues.

    Don’t jump into the deep end of the DevOps pool just because everyone else is. Before embarking on your DevOps journey, do a deep analysis of your organization’s goals and baseline your current levels of performance. Discuss what needs to change based on real business goals and drivers (e.g., it takes us too long to issue regulatory changes to the system). Identify bottlenecks and constraints that exist in the current environment today and put together a plan to eliminate as many as possible.