devopsy.kinsta.cloud

Tag: devops culture

  • A Holiday Tradition: 2017 Continuous Delivery Predictions

    A Holiday Tradition: 2017 Continuous Delivery Predictions

    It’s that time of year. As the calendar year comes to a close, many of us are following time-honored traditions: making preparations for the holidays, planning some much-deserved time off and enjoying time with friends and family.

    In the business world, the year-end also brings its own traditions, and first among those is making predictions for the coming year. I’m not one to forgo traditions, so in this article I’ll share my thoughts on the upcoming year within the context of the continuous delivery movement.

    To level set, continuous delivery is the most evolved and modern state of software development and testing—and is core to a successful DevOps strategy. Organizations that are able to achieve continuous delivery can rapidly develop, test and release applications—with higher quality and at lower costs.

    Simply put, the ability to more continuously deliver software is one of the biggest advantages to attain in the application economy, where the battleground for consumer loyalty is most often found in the ability to deliver superior applications.

    Now that we know what continuous delivery means, let’s get to my predictions for 2017:

    1. Continuous Delivery Means Continuous Everything

    Continuous delivery is still a relatively new concept, and one that many organizations strive to achieve. As a new concept, it suffers from some of the misconceptions that often plague emerging technologies or trends. Many technology providers latch on to the term and claim to provide “continuous delivery solutions” that in reality only address a small part of the continuous delivery challenge.

    Truly delivering software continuously means that all the tasks within the software development life cycle (SDLC) must be optimized to occur in parallel and continuously. This means development must be continuous, testing must be continuous, and likewise for release and operations.

    2017 will be the year that industry embraces the importance of an end-to-end continuous delivery value stream. In 2016, many organizations began their continuous delivery journey by addressing certain aspects of the SDLC; in 2017 many organizations will begin to realize a truly open and integrated continuous delivery workflow.

    1. Democratization of Continuous Delivery Tools (via the Cloud)

    Optimizing all aspects of the SDLC for continuous delivery, as mentioned above, means that related tools need to be easier to use and easier to access. Developers who have access to testing tools (left-shift) can improve the quality of code they produce. Similarly, QA engineers who have access to design requirements sooner can create more accurate test data and scenarios, earlier.

    However, for this to occur, the tools have to be both easy to access and simple to use. Developers have avoided complex testing frameworks, but with simple, easy-to-use tools available—often in SaaS forms—developers can certainly incorporate testing into their methodologies.

    In 2016, CA acquired BlazeMeter, which pioneered the notion of cloud-based performance testing employing a simple and easy-to-use (yet very powerful) product. We expect to see this trend expand into other tools within the continuous delivery value chain in 2017.

    1. The Industry Embraces Open Source (Really)

    In the past, we’ve noted that commercially motivated technology providers have tried to keep open-source technology “at arm’s length.” There may have been some lip service paid to openness, but in reality many commercial providers felt threatened by open-source solutions that were seen as competitive to their products.

    This perception has already started to change, but I believe 2017 will mark the tipping point where companies will truly embrace open-source solutions as part of their strategy; those companies that continuously resist (pun intended) will be at a significant disadvantage.

    Open source is important for many of the same reasons as the cloud: It is broadly adopted because it creates advantage in time to market, quality and cost effectiveness. Embracing open source—and by that I mean both integrating with open-source solutions and using them as part of a product strategy—only makes good business sense. It helps software development teams meet their objectives in delivering quality software faster, and at lower cost.

    Another year is rapidly coming to a close and we have a lot to look forward to in 2017.

    On the topic of continuous delivery, looking forward means spreading continuous delivery throughout the SDLC, using the cloud more and embracing open source.

    All of those things combined will help us advance the continuous delivery movement together as an industry. Here’s to another year of continuous delivery advancements!

    Don’t forget, you can also take a closer look at the ongoing evolution of continuous delivery and other DevOps-related trends by picking up a copy of my colleagues’ new book, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory.” If you have some extra time over the holidays, you’ll find it to be an interesting deep-dive.

    — Jeff Scheaffer

  • Assembling the Key Components of Continuous Delivery

    Assembling the Key Components of Continuous Delivery

    As agile methodology was popularized at the start of last decade, engineering teams gained the opportunity to begin producing software in shorter cycles, while releasing it reliably at more frequent intervals.

    This concept garnered greater attention in 2009, when Tim Fitz published his thoughts on continuous deployment. By the time Jez Humble authored his seminal book, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation,” in 2010, the approach started to get significant mindshare. In the book, Humble advanced the three building blocks of continuous delivery: configuration management, continuous integration and continuous testing.

    Thereafter, Agile Operations—the practice of using end-to-end monitoring, fueled by analytics, to increase operational agility—appeared. This complemented continuous delivery, with the goal of increasing the quality and velocity of software delivery while minimizing overhead.

    Since then, and particularly over the last six years as DevOps adoption has exploded, there’s been significant discussion (and confusion) over the opportunity to embrace “continuous everything” across the software development life cycle (SDLC) to deliver functionality continuously and optimize end-user experience.

    Today, having spoken to hundreds of organizations employing agile and DevOps, it’s possible to expand on these concepts to better define the key components of continuous delivery.

    In this blog, I’ll detail the precepts of “CD” that CA’s customers recognize as critical in reducing the time, risk and expense of software delivery by frequently releasing smaller batches of code with extensive visibility and traceability.

    These building blocks of continuous delivery are:

    • Continuous development & integration,
    • Continuous testing. and
    • Continuous release.

    Continuous Development and Integration

    When it comes to delivering quality apps faster, every second counts.

    That’s why it’s important to automate the planning, development, unit testing and integration of code with different inter-dependent components, all while packaging it for quality assurance. We categorize these activities under continuous development and integration, as shown in Fig 1.

    This all starts with sprint planning and modeling of requirements in agile management software. Unit tests can be created automatically, based on requirements and use case stories. These unit tests then can be executed automatically based on pre-defined criterion, using automatically generated synthetic data.

    Fig 1: Continuous Development and Integration

    Next, virtual service interfaces can be generated automatically by simulating unavailable systems across the SDLC, allowing developers, testers, integration and performance monitoring teams to work in parallel—driving faster delivery, along with higher quality and reliability.

    The integrated code can be built and tested automatically against validation criterion, and upon passing, made available for continuous testing. This later phase, after code development and before QA, is also commonly referred to as continuous integration.

    Continuous Testing

    Continuous testing across app delivery not only enables enterprises to shift testing left, engaging it earlier in the SDLC, but it also helps them shift right, leveraging the same processes throughout staging and production.

    After the unit tests are passed and integrated builds are made available for QA, functional and performance tests can be completed—before the build is made available for staging and production. Various activities during continuous testing are shown in Fig 2.

    Before the functional and performance tests are performed, the build promotion criterion and configuration also need to be validated. Testers require provisioning of QA environments to deploy the build, along with virtual services and test data. Using test data management to create a subset of production data and mask sensitive information is another continuous testing requirement.

    Fig 2: Continuous Testing

    It’s also important to engage application performance monitoring in the QA environment before running automated tests, providing feedback about any problems back to developers.

    After the automated tests are executed and promotion criterion are met, the build is ready for deployment in staging or production environments.

    Continuous Release

    Continuous release matches release velocity to development velocity through controlled and scalable deployments.

    The goal of continuous release (sometimes referred to as continuous deployment) is to continually and automatically deploy the build into production; similar activities also can be performed in a staging environment.

    As shown in Fig 3, build configuration needs to be validated, with the production environment configuration updated before being sent to production. As with application code, configuration is also maintained in the version control system and can be automated for deployment.

    Fig 3: Continuous Release

    After the build is deployed into production, application monitoring should be initiated to track performance and customer experience. Feedback from the production environment can be passed back to developers to guide enhancements or sprint backlogs.

    This blog aims to outline core CD activities, and in subsequent articles I’ll provide additional details on entry and exit criterion, as well as metrics useful in tracking continuous development & integration, continuous testing and continuous release.

    In the meantime, check out, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory,” a new book authored by my colleagues Aruna Ravichandran, Kieran Taylor and Pete Waterhouse.

    Based on learnings gained from numerous customers who have already embraced CD and DevOps, it highlights key practices for starting this journey, related ROI metrics and other useful tips.

    — Anand Akela

  • Every Business Has Become a Technology Business

    Every Business Has Become a Technology Business

    Contributor: ITSM ACADEMY-Drew Lapatin

     

    Every business has become a technology business.

    Let that one sink in for a moment.  With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog), and when should we retire them (retire).  We literally could be an app away from becoming irrelevant.

    It is no longer enough to satisfy our customers, we must now delight and excite them.  They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often.

    By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer requirements more effectively. Normally projects will start with a given set of requirements.  In an Agile project (yes, we are going to use an Agile project format to continue the theme of blending ITIL and DevOps) the product backlog will contain these requirements as user stories, but as we all know those stories/requirements/attributes can change very rapidly. One tool that could help us rank these attributes and ensuring the delight of customers is the Kano model.

    A Kano model shows us there are three different factors in customer satisfaction.

    They are as follows:

    • Basic factors are aspects of the service that have to be in place for the customer to receive the service. They may not offer any obvious value, but if they fail, or are not delivered, customers will become very dissatisfied. These factors are sometimes called ‘must-have utility’ or the very least the service provider can deliver for a particular service.  Basic factors are not responsible for high levels of satisfaction, unless they alone fulfil the customer’s requirements completely.
    • Performance factors are factors that enable a customer to get more of something that they need, or a higher level of service quality. These are the factors that customers are interested in and the price they are willing to pay is directly impacted.  These factors result in customer satisfaction when delivered and customer dissatisfaction when unfulfilled.
    • Excitement factors are attributes of a service that are generous, and which customers do not expect. When they are offered (within reason) they cause higher levels of satisfaction. The service provider is seen to be ‘going the extra mile’. While excitement factors result in the quickest and highest levels of customer satisfaction, they are expensive to maintain, since the service provider is offering more than necessary at the same price. These factors may be exciting, but they are not essential to the service, and are therefore also referred to as ‘nice-to-have utility’. Internal service providers should be careful of introducing excitement factors in the interest of ‘customer satisfaction’ without doing a proper business case to justify the additional costs.

     

    Drew Bio

    — Alice Acedia

  • DevOps: Using Games to Make it Practical

    DevOps: Using Games to Make it Practical

    This blog stems from my experience of being one of the earliest DevOps Foundation trainers of DOI and successfully completing 19 batches of DOI Foundation course in the last year.

    In retrospect of the year starting when TaUB Solutions signed up as a registered education partner (REP) of DOI, my opinion is this has been the best service portfolio offering for our customers and partners.

    There are few things that appeal best when it comes to DOI Foundation course and I can summarize them with the collective feedback I’ve received so far:

    “Challenges the preconceived myths and practices around DevOps with practitioner stories.”

    “Gives a holistic overview of philosophy behind DevOps. Philosophy should precede science and science should precede engineering.”

    “This course maintains the discipline to be truly advisory in nature by illustrating tool chain without recommending vendor-specific tools.”

    “The group exercises during the class and the facilitator practical insights helped us to put the aspects in to our organizational context of delivering products and services.”

    “We have never seen a course such beautifully designed that could be the first basic building block to know ‘Do’s’ and ‘Don’t’s’ of DevOps across application developers, infrastructure operations, project managers, infosec professionals and business leaders.”

    To enhance the overall learning curve of the audience, we put them in to the third day of experiential learning using the Phoenix Project Business simulation. The simulation was divided into four rounds and played with maximum of 12 people per batch. The Team was entrusted to achieve a target of $300,000 within four rounds and take the share value from $21 to $45.

    While the target milestones were clearly laid down at the beginning of game it was difficult for the teams to get hold of the situation due to various unknown parameters. It took them quite sometime to understand the different moving parts of flow, dependencies, business impact of projects, issues and features that came up in every round and make  appropriate choices and decisions.

    The teams experienced significant learning, sharing and collaboration over the four rounds and had loads of fun. One common feedback from the teams was for the game to be mandatory after every two-day DevOps Foundation course.

    The consolidated feedback after playing the DevOps business simulation after the two-day course:

    “It demonstrated that it is not easy to build collaboration, communication and integration. It takes time and there is a lot of patience and team work needed to make this a reality. The DevOps culture had to be nurtured through self-organizing teams with mutual respect, sense of pride and collective ownership to work toward a common goal.”

    “It gave a working knowledge on how ITSM and DevOps are complementing each other [Ex. Change Management and Improved Flow].”

    “The Principles of DevOps, namely the First Way (Improve Flow from left to Right), Second Way (Shorten Feedback Loops) and Third Way (Repetition through Mastery) was visibly evident over the course of four rounds.”

    “The speed of execution improved over the rounds using short feedback loops, continual improvement and applying lessons learned from previous rounds.”

    “It gave a good understanding of how different roles and responsibilities in the organization contribute to the overall success of the project.”

    Finally, the teams made over and above the required target of revenue and stock price. The winning moment was enhanced by the significant learning opportunity and ability to bond with diversified cross functional teams.

    The experience of playing the business simulation reinforced practical understanding of DevOps and also transferred skills that they could implement immediately at their workplace.

    About the Author / Suresh GP

    sureshSuresh GP is the Managing Director of TaUB solutions and Regional leader of BRMI (APAC). He has more than 15 years of experience in IT Service Management, IT Governance, Program Management and Organizational Change Management. He is regular blogger and International speaker at itSMF UK, itSMF Australia, itSMF USA, itSMF Finland and itSMF Norway. He is a Certified DevOps, Agile Service Manager, Business Relationship Management Professional, PMP, CGEIT, ITIL V2 Service Manager, ITIL V3 Expert,  ISO 20000 practitioner. He was awarded the ITSM contributor of the year by itSMF Singapore in 2013.

  • Introducing DevOps Express!

    Introducing DevOps Express!

    The DevOps Institute (DOI) is proud to join industry leaders as a founding member of the DevOps Express. The DevOps Express is a bold initiative between tool providers and others to create a solutions-oriented approach that will make enterprise DevOps adoption easier using popular technologies spanning multiple solution components. Working together, DevOps Express members have committed to improving interoperability within the DevOps stack, and creating a framework for industry partners to develop reference architectures that will be better integrated with better support.

    The 14 founding members of DevOps Express include vendors spanning multiple solution categories in the software delivery process, as well as service organizations providing consulting, training and professional services:

    • CloudBees
    • Sonatype
    • Atlassian
    • BlazeMeter
    • CA Technologies
    • Chef
    • DevOps Institute (DOI)
    • GitHub
    • Infostretch
    • JFrog
    • Puppet
    • Sauce Labs
    • SOASTA
    • SonarSource

    DOI is honored to be a part of this important and innovative program. We believe this initiative represents the industry’s commitment to “walking the DevOps walk” by agreeing to collaborate, align and integrate for the betterment of the market. We are excited that major industry partners are unifying to give enterprises potential starting points for creating a DevOps stack, while also increasing quality and lowering risk. As knowledge, best practices, architectures and models emerge from the work of DevOps Express, DOI will ensure that these are available to the DevOps learning community and embedded into DOI courses, articles and future member benefits.

    The DevOps Express is leaving the station, and DOI is on board! Read the press release for more information about this historic initiative.

  • Communication Skills Matter in DevOps

    Communication Skills Matter in DevOps

    While the precise definition of DevOps is an evolving matter, a simple way to describe it is this: DevOps is a change of mindset toward an agile and inclusive approach to IT. DevOps enables IT professionals to think and work beyond technology silos, thereby deriving meaningful results at a faster rate than with more traditional methodologies.

    This involves going outside of our comfort zones and collaborating outside the confines of our own cliques. By working across operational boundaries, DevOps will require an understanding of technical, operational and service aspects of the business. This means the heart of DevOps lies not in technology, methodology nor administration: The heart of DevOps lies in communication, which brings all these together.

    DevOps professionals seem to agree. In Incapsula’s DevOps Salary Survey conducted in 2015, the California-based cybersecurity firm identified communication skills as one of the highest priorities for DevOps professionals, almost as much as operational skills.

    In other words, effective communication across the organization is considered as important as actually building the product, and it is integral to building the product itself. This means when you’re in the field of DevOps, a smart investment in communication skills will pay off for both individuals and the team.

    Communication Fosters Teamwork

    There usually exists a disjoint between technical and non-technical departments, particularly in technology companies. Engineers, for example, might be fascinated by an elegant piece of code, an algorithm that automatically governs a process or an infrastructure that does exactly what it’s supposed to do. But to the rest of the organization, those things take place purely in the background and work best when they aren’t noticed at all.

    Tech people take pride in the technology, while operations people take pride in business results. The two often find themselves at odds due to a lack of communication about what is really needed, and how to get there. Successful communication in DevOps focuses on finding common ground and working toward achieving this.

    For communication to be effective, the emphasis should be on the user of your message. You’ll need to have a deeper understanding of where they’re coming from. No amount of expertise matters if you can’t convey it properly. You can’t gain any growth or value for your career or organization if there is always a unidirectional disconnect.

    Bottom line is, you need to correctly identify your intended recipients and find a common ground to better engage.

    You Can Increase Your Value as a DevOps Pro

    Trust is an essential component of teamwork, which is also important in the development life cycle and in decision-making processes. Being a communicator enables you to better establish trust among your colleagues—something that, unfortunately, is lacking in many IT project life cycles.

    This is why pure technologists don’t necessarily make good DevOps professionals—an observation highlighted by the Incapsula survey, which shows that a mix of general and technical skills are essential for a successful DevOps career. In fact, general skills are usually more important in securing higher-paying jobs in this field. These include understanding business operations, developing communication skills and remaining flexible and open to change. In addition, the rising trend in outsourcing DevOps pros across a global talent pool means your communication skills have to transcend languages and contexts.

    A good DevOps professional knows that value is not just about the technology, but rather about the product. Even the best technologies in the world are just abstract concepts until you translate them into a product people can actually use and enjoy. Thus, going beyond technical capabilities, you will need to know how to collaborate to transform technologies into useful and marketable products.

    You Can Advance Your Career Faster

    Chatting up the project managers, glad-handing the operational staff and picking the brains of departmental leaders may not come naturally to pure technologists. However, for DevOps professionals increasingly engaged in conversations across the enterprise, knowing the language unique to the organizational culture—verbal and nonverbal—can make all the difference in terms of career advancement.

    Such organizational language can be considered as its own kind of coding. This facilitates everything from a working knowledge of financial reporting, to the listening skills needed to understand the technology goals meaningful to each business unit. It’s also how unwritten rules about business priorities or hierarchies are communicated.

    After all, the career survey cites at least 26 job descriptions among DevOps professionals, including project manager and operations manager, among others. This means you don’t necessarily have to get stuck in one position or job description. In an organization that fosters the DevOps culture, your value goes well beyond your technical capabilities, but rather the focus is more on organizational skills.

    The Takeaway

    Since DevOps involves cross-functional teams instead of compartmentalized departments, everyone will need to be more involved in business operations, product development and support. Being an effective communicator is at the heart of all this, and it can spell the difference between success and failure in a DevOps environment.

    It’s easy to think that there is little more to learn in terms of communication, especially if your DevOps integration is already mature and your team is functioning optimally. However, your investment in becoming a better DevOps communicator begins with learning the language and culture of the organization. This also includes a continuous reassessment of skills and the ability to build connections from each and every encounter with colleagues, partners and other stakeholders.

    About the Author / Laureen Fagan

    LaureenFaganA senior PR counsel and thought leader, Laureen Fagan has 15 years experience as a media and PR professional, which includes her stint at CBS and Fox broadcast affiliates in the United States, and in print and wire-service newsrooms in Chicago, Washington D.C., and Jerusalem. Laureen received her MSJ from Northwestern University’s Medill School of Journalism, and completed additional graduate study at University of Notre Dame in Theology / Hebrew Bible that includes French, Arabic and Hebrew study. In addition to tech and business, Laureen creates informed content and deep analysis on international affairs, health care, culture and religion.

     

  • Can Culture Detract from Success with DevOps?

    Can Culture Detract from Success with DevOps?

    Collaborative culture is considered to be an essential best practice for enterprises. DevOps culture correlates strongly with enterprises that achieve the highest level of business performance. However, is it possible that an organization can get overly fixated on organizational culture improvements? Can culture actually detract from achieving success with an enterprise DevOps transformation?

    An article by Curtis Franklin Jr.,”8 ways to fail at DevOps,” indicated that there are “plenty of places in the DevOps process where an organization can run aground on rocky shoals of woe.” My blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps. One of the seven pillars is collaborative culture. These pillars are not silos, but rather foundations that need to be kept in balance.

    I bet most of us have experienced situations in which cultural improvement missteps hindered an enterprise DevOps transformation.

    Culture Missteps

    I’ve listed some examples l below which I have personally seen. Have you experienced these? I would love to hear examples of your experiences and solutions you have observed, too.

    1. Unrealistic expectations from leadership: Business expectations from leadership get too far ahead of the DevOps implementation reality—then teams reporting to leadership end up feeling unappreciated and experience frustration, resulting in organizational friction.
    2. Ops-side transformations fall behind Dev-side transformations: The Dev team accelerates ahead of the Ops team and implements “its part” of a DevOps transformation before the Ops team has a chance to implement complementary changes. The Dev-side is disappointed that Ops has not kept up with the complementary Ops-side planned changes. Dev changes cannot be put into effect, which deepens the mistrust between Dev and Ops.
    3. Dev-side transformations fall behind Ops-side transformations: This is the reverse of the second example, with similar effects.
    4. QA tester roles are confusing: When new continuous test strategies are implemented, the lines of test responsibilities between Dev, QA and Ops team members became blurred. Communication between cross-functional team members become confused, resulting in misunderstandings, dissatisfaction and organizational friction, which obstructs progress.
    5. Infrastructure and tools teams are siloed: Dev, QA and Ops teams maintain separate, siloed tools and infrastructure staff and do not cooperate to support end-to-end infrastructure and tools improvements. The transformation needed for a smooth DevOps pipeline stalls.
    6. Rewards and measures are not consistent with DevOps goals: The organization makes changes toward a cooperative culture but fails to change the way people are rewarded and measured. Conflict results between the teams.

    Solutions

    Below are solutions that were applied to the situations listed above. Do you agree with these solutions, or have others to suggest?

    1. Leaders were coached to be more aware that DevOps transformation is a journey of continuous improvement. Leaders then understood that there is really no “end state” to DevOps—there are specific business improvements that can be expected along the way. Each DevOps improvement initiative was refocused on realistic specific use cases and goals. With improved clarity, leaders were more realistic in their expectations for each improvement. This drove alignment between leaders and their teams, improved satisfaction and productivity.
    2. Project goals and team meetings were realigned and organized. Dev and Ops sides could monitor end-to-end progress together. When situations occurred in which one team got ahead of the other, the end-to-end progress visibility helped overall group communication. Empathy across the Dev, Ops and QA teams improved. With improved communication, team members celebrated the success of each other’s improvements. Teams shared a common end-to-end goal.
    3. Same as 2.
    4. QA testing responsibilities changed significantly during the DevOps transformation. Separate independent test team member responsibilities changed toward QA testers being more integrated with Dev teams. New skills requirements for the QA engineers emphasized test automation more than in the past. Training for the cross-functional team helped mitigate concerns related to the new QA responsibilities. QA testers were uplifted with new skills and became more valuable and respected by their peers. Cross-functional productivity improved.
    5. The tools and infrastructure teams from the separate Dev, QA and Ops teams were combined into a common tools and infrastructure team. Project goals were realigned. The improved clarity around knowing they are working toward tools and infrastructures for a common end-to-end pipeline accelerated implementation of DevOps.
    6. Rewards and measures that had been in place for separate Dev, QA and Ops roles were changed to rewards and measures that encouraged end-to-end cross-functional team activities. This improved overall morale and job satisfaction and reduced organizational friction that was previously impacting progress.

    Summary

    From the above real-life examples, it is clear to me that culture and organizational practices must evolve in concert with progress on other DevOps pillars. And as the pace of change increases with each transformation, the cross-functional teams must be even more cohesive. Continuous acceleration of interactions between team members drives the need for tighter relationships, more end-to-end responsibilities, improved customer awareness, continuous skills training and end-goal focused leadership.

    The is no need to create the “perfect culture” before starting a DevOps transformation journey. It can be counterproductive for sections of the culture to get too far ahead of itself, as indicated in the examples above. Perhaps it is best to evolve the culture carefully. Changes most important for each transformation project should be the focus. Continuously communicate goals and progress, and evolve the culture together with evolution of other pillars. What do you think? Do you agree is it possible that an organization can get overly fixated on overall organizational culture improvements?

    While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all of their IT systems.

  • REP SPOTLIGHT: Daysha DevOps Solutions

    REP SPOTLIGHT: Daysha DevOps Solutions

    DevOps Institute: Tell us a little about your organization.

    Daysha DevOps Solutions: Daysha DevOps Solutions is a leading IT services and solutions company focused on helping companies to deliver their IT projects, transform their capabilities and ultimately to provide value to their customers and stakeholders. Our goal is to help organizations benefit from disruptive technologies, such as cloud computing, Lean/Agile software development and DevOps. We work across a range of industries including financial services, government, aerospace and high-tech.

    Daysha DevOps Solutions has partnered with the best-in-class product vendors to help organizations improve their ability to deliver software quicker, more frequently, with higher quality and less risk. Our DevOps solutions address all stages from project planning right through to deployment.

    DOI: What other topics do you teach or consult on?

    Daysha DevOps Solutions: Daysha bring proven expertise and consults across the wide domain of DevOps. Partnering with vendors such as Atlassian, App Dynamics, Chef and Zephyr, we offer expertise, training and tooling to support all aspects of the DevOps journey.

    Our IT Project Services team consists of experienced IT consultants including project managers, technical experts and business analysts. These can be deployed to help augment your existing IT teams or to provide specific project help, such as requirements gathering, gap analysis and process improvement.

    DOI: What type of interest in DevOps are you seeing in your region?

    Daysha DevOps Solutions: The interest in DevOps is growing, though to be honest, a lot of organizations are wary of it. That said, the same organizations are heavily rooted in traditional waterfall environments. There is a recognition that DevOps is the way forward but also a realization that cultures need to change first.

    DOI: How do you think that DevOps contributes to the business’ value stream?

    Daysha DevOps Solutions: Primarily by delivering value earlier and increasing the visibility of the IT contribution to the business stream.

    DOI: What topic area in DevOps excites you the most?

    Daysha DevOps Solutions: How business can get more value from IT. In other words, turning an IT department into a revenue-generating tool rather than a cost.

    DOI: Why should enterprises and individuals consider formal DevOps Training?

    Daysha DevOps Solutions: It is the first step, and a certified first step, on the road to improving the value of IT functionality.

  • What DevOps Skills are Organizations Looking for?

    What DevOps Skills are Organizations Looking for?

    DevOps is a cultural, philosophical and organic approach toward automating workflow and getting products to market more efficiently and effectively.

    DevOps engineers are in top demand right now. According to studies by Gartner, 25 percent of top global 2000 organizations will have adopted DevOps as a mainstream strategy by the end of 2016.

    DevOps is both a cultural movement and a philosophy … which can make it difficult to define the specific skill set you need a DevOps team to possess in order to function successfully.

    Of course, an excellent way to show fluency in DevOps is by earning a DevOps Institute certificate—for example, DevOps Foundation®.

    That being said, there are some “mission-critical” DevOps skills that organizations are searching for pretty universally right now.

    1. Experience with infrastructure automation tools and fluency in web languages

    Experience with tools such as Ansible, SaltStack, Puppet, Docker, Chef and Windows PowerShell DSC as well as fluency in languages including Ruby, Python, Java and PHP are must-have skills for DevOps pros.

    Organizations are searching for DevOps candidates who are highly proficient in many of these tools and languages and open to increasing their competencies further when given the opportunity to do so.

    2. Expertise in “soft skills”

    DevOps evolved as a way to enhance collaboration across project life cycles and connect front-end and back-end professionals on either side of the software development and operations spectrum.

    When software developers and operations staff (system engineers, systems admins, DBAs, etc.) collaborate effectively, communicate honestly and work as a cohesive team, the software development life cycle (SDLC) is streamlined, risk factors are mitigated, and projects are completed and deployed with a minimum of bugs, quality defects and glitches.

    In addition, it can be useful for organizations to have DevOps specialists on their team who are comfortable in the role of client consultant, able to interact effectively and build positive business relationships with customers while addressing their needs and wants.

    Organizations look for DevOps candidates who are skilled in interpersonal communication, with an arsenal of listening, negotiation, problem-solving and team-building skills at the ready.

    3. Familiarity with CI (continuous integration) tools

    Continuous integration is a DevOps methodology that continually merges source code updates from all developers on a specific software build, notifying the team of any failures in the process.

    This offers a real-time window into the developing software system, allowing immediate and constant engagement of all team members throughout the project lifecycle.

    CI tools DevOps candidates should be familiar with include CruiseControl, CruiseControl.NET, Jenkins, Bamboo, Hudson, ThoughtWorks’ Go, Urbancode’s Anthill Pro, Microsoft’s Team Foundation Server and Jetbrains’ Team City.

    4. Bonus Skills

    Other skills hiring managers are on the lookout for in the DevOps space include:

    • Extensive knowledge of software build cycles
    • Experience deploying code
    • Experience in software architecture
    • Familiarity with application programming
    • Database management
    • System design

    Useful experience and certifications include:

    • Project Management
    • Risk Management
    • Scrum Master

    The good news is that the industry’s need for DevOps team members with diverse and evolving skill sets is in sync with what DevOps candidates want from their workplace. According to the 2014 State of DevOps Report from Puppet Labs, an atmosphere conducive to learning is a primary component of job satisfaction among DevOps engineers.

    About the Author / Robin Borough

    Robin BoroughRobin Borough is President of Omnikron Systems, Inc., which offers IT and management training and IT staffing services. As an advisor to technology professionals and executives for over 25 years, Robin has built a world-class reputation as a “go to” career strategist in the IT industry, one who’s capable of successfully guiding executives and specialists, at any level, through transition. 

  • Unconventionality within Constraints

    Unconventionality within Constraints

    What do dependency resolution, situational awareness and superheroes have in common? Meet Chris Corriere, a DevOps/software engineer at Autotrader speaking on creative ways to maximize usage of all of the above. Mark Miller, community advocate and senior storyteller at Sonatype, caught up with Chris to learn more about what his team is up to.

     

    Chris Corriere

     

    Corriere: I’m Chris Corriere, and I’m a DevOps engineer at AutoTrader.

    Miller: Can you give us an overview on how you’re using Nexus?

    Corriere: We use Nexus for dependency resolution. Part of that is to insulate our enterprise infrastructure from general third-party dependencies. We’re able to filter that down with our internal repo and make sure that our developers are using things that are pre-approved, that we’re allowed to track and update. We also use it to move around internal projects that have cross-dependency between applications in-house.

    Miller: How are you enforcing pre-approved dependencies?

    Corriere: They are generally around who has access into Nexus and who is allowed to improve and pull things into Maven Central. But there are ways around that. There are ways to sneak things into builds. If a developer really wants to get something in then, sometimes when you’re troubleshooting, you find some of those clever solutions. There’s definitely an element of striking balance between that, of making sure they’re able to experiment and get the tools in they need to get their job done, but not exposing any liability or risk in the process by pulling something in that’s not trusted.

    [soundcloud url=”https://api.soundcloud.com/tracks/270488651″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

    Miller: If somebody isn’t using a binary repository, what could you tell them that would get them to use one?

    Corriere: Consistency within the build environment is one of the main draws to me, that and reusability of code. I think that doubles back into situational awareness—depending on how they’re measuring their organization, what they’re looking for in terms of improvement, and where there’s room the optimize. There’s probably a lot of interruption in build, a lot of different permutations. I’ll say in different solutions, it could be more standardized and more consistent across teams. You can get by without it. But you’re probably doing a lot more work for the same end result. Without a repo, there’s a lot more drama, a lot more heartache involved.

    —

    “Without a repo, there’s a lot more drama, a lot more heartache involved.”

    —

    Miller: I would think that the more developers you had, the more you would actually have a real need for it.

    Corriere: I would say the most creative solution I’ve seen is teams get pretty consistent results with using source control and builds at particular revisions. But in that instance you have to have the build to succeed. You have to get through the build, and that’s going to take time even if it doesn’t break. Your repository is putting everything after that step where it’s ready to go. You know it’s built. You know it’s safe. It didn’t get into the reboot. It didn’t make it through the filter.

    Miller: Have you guys done anything cool with Nexus?

    Corriere: I wouldn’t say anything too out of the ordinary. There’s some overlap into how we’re leveraging it that looks more like configuration management, which is unconventional. Depending on the project, you’re able to check some things from Nexus and how they will stand up [against] a lot of your environmental dependencies outside of just a job application. It can dip into the version of Java you’re running, different inch grips, and other things that nest into each other. That gets you to sort of square one to launch a lot of our standard internal apps. Again, back to the situational awareness, given some of the constraints of the teams we were working with, it’s something I ran across and it felt a little left handed at first. But when you stop and look at it, they were able to get the ball moved down the field within the constraints that they were given. At the end of the day, it works.

    Miller: Are you using any continuous integration, continuous delivery?

    Corriere: Yeah. I don’t think that’s a boolean of a value. We’ve got a lot of it end over life cycles, and we’re running continuous builds. We’ve got some in-house tooling around that, and we also run Jenkins. There’s always room to accelerate, improve and optimize it. We’re moving to more continuous delivery. We really want to start getting things out closer to prod. But you always start with the left side and move out from there, and try to debate quality from step one where there’s lower risk. I’ve seen AutoTrader make a lot of good strides in that over the past couple years.

    —

    “There’s always room to accelerate, improve, and optimize it. ”

    —

    Miller: Final question, if you were going to be a superhero, would it be in Dev, Ops or Sec?

    Corriere: I’m going to go with security because I think there’s some development and operations involved in that if you’re doing it right. I don’t think you should be blue team or red team. I think team purple is where it’s at. You really got to come at it from both ways to get the job done today.

    —

    “I don’t think you should be blue team or red team … purple is where it’s at. You really got to come at it from both ways to get the job done today.”

    —

    Miller: Excellent. Thank you, Chris.

    Corriere: My pleasure.

    If you loved this interview and are looking for more great stuff on DevOps, I invite you to download the “Continuous Delivery and DevOps Reference Architectures,” highlighting real-world DevOps practices from organizations including PayPal, IBM, Adobe, USPTO and many more.

    DevOps