Category: Enterprise DevOps

  • Do Regulatory Auditors Hate Continuous Delivery?

    Do Regulatory Auditors Hate Continuous Delivery?

    In a world where superior customer engagement and other market imperatives depend on having the right code in production sooner rather than later, continuous software delivery is a competitive necessity

    But you can’t get code into production unless you properly test it. And you can’t properly test code without appropriate test data.

    And that’s where the regulators come in.

    Solving for Personally Identifiable Information
    Production data is rife with personally identifiable information (PII) and other compliance-sensitive content. That data is typically well-protected by various security measures and access controls in the production environment itself. But putting that data (or, more precisely, a sample set of that data) in a test environment exposes it to significant security and compliance risks.

    For one thing, test/QA engineers aren’t account managers or clinicians. So, from a regulatory perspective, there are certain kinds of data they shouldn’t be allowed to see. For another, test/QA environments are typically not secured in the same way as production. Worse yet, test/QA is often performed by contractors — and may even occur offshore. This creates unacceptable security risks and throws up big red flags for regulatory auditors.

    To protect PII while enabling thorough and effective testing of new code, companies use synthetic data and other masking/obfuscation techniques. That’s what regulators demand and expect.

    Yet another roadblock?
    Unfortunately, most companies generate test data on a very ad hoc basis. At some point in each project, someone realizes they’re going to need some test data — and they set about creating it. But without a global mechanism for determining what needs to be masked and actually performing that masking, the undertaking becomes iffy and time-consuming. Not all the data that needs to be masked gets masked. A couple of developers may independently decide that the best thing to do is write a one-off script. And if the script doesn’t work well, the team may just cross their fingers and opt to forego masking altogether.

    Hence the title of this blog. Of course regulators don’t actually hate continuous delivery. Most of them probably don’t even know what it is. But their mission — enforcing the diligent protection of sensitive data — can be a serious obstacle to continuous delivery for companies that don’t get their act together when it comes to test data management.

    The solution: Continuous compliant delivery
    The only way to reconcile the requirements of regulatory auditors with the need of the business for continuous delivery is to adopt a well-managed enterprise-wide mechanism for test data creation. Such a mechanism accelerates every code promotion workflow across every project, while also providing an auditable means of enforcing PII masking/obfuscation policies. Enterprise test data management also reduces devops costs by eliminating the need to re-invent the data-masking wheel on every project.

    So, no, regulators don’t hate continuous delivery. But they could — if companies sacrifice compliance for speed. The best way to avoid that sacrifice is to embrace enterprise-class masking discipline for test data.

    About the Author/Aruna Ravichandran

    ravichandran arunaAruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is  on twitter @aruna13 and on Linked in

  • Follow the Unicorn: Transform your Enterprise Applications

    Follow the Unicorn: Transform your Enterprise Applications

    For those of us that work on Enterprise Systems such as the mainframe, the claims that the Unicorns (1) make, can be pretty astounding. Dozens and sometimes hundreds of releases a day from big companies like Netflix (2) and Etsy (3) are hard to comprehend. But look a little closer and you can see that the key difference is in the way changes are released to customers, not so much the total volume of changes. A traditional enterprise application may have thousands of changes made over the course of 3 to 6 months, but all of those changes are released at once. The Unicorns are typically able to release a very small number of changes at a time because they can develop, build, test, and deploy these changes very efficiently. Small batch releases to customers has significant value. It enables you to get feedback very quickly, and it is significantly easier to verify because the change is not mixed in with other changes.

    So how can you transform your development environment to deliver small batch of changes? I like to tackle the problem like any other computer science problem, no doubt because of my background. Break the large problem into a set of smaller problems and then solve those smaller, less daunting problems:

    Step 0: Start with a Proof of Concept

    Pick a Proof of Concept (PoC) to begin with that is important, but not mission critical. The PoC can be used as a learning ground and hopefully as a template for subsequent PoC’s. Make sure you have a team that culturally is willing to transform. Often the hardest issues to tackle have nothing to do with technology, but are cultural.

    Step 1: Understand your Application

    You need to have a good understanding of what your application consists of. Not only does the source code make up the application, but what source files are used, what the middleware configuration might be, what scripts you may have to build and deploy the application, and what data files (e.g. flat files, databases) that you use are also important. Some of these components may be shared with other applications, so you need to understand those dependencies as well. Once you have a good handle on the application, you can then automate the application build and deployment process so that all members of the team can work efficiently.

    Step 2: Understand your test cases

    If you can build and deploy the application quickly but it still takes days or weeks to test, then testing prevents you from delivering to your clients. An important shift for testing needs to be from testing the entire application to testing the change. You need to focus on running the right tests to ensure the change is correct and causes no regressions. Tests that do not exercise the code change are irrelevant and can be skipped. For many existing applications, the test suites may consist of hundreds if not thousands of test cases. Many of those test cases may be duplicates or testing areas of the code that are not being changed.

    Step 3: Understand your processes

    How fast can you get your updates to your customer? If your bug fixes and enhancements have to sit on the shelf for days, weeks or months before the customer gets them, they will not be satisfied. Streamline not only the development processes but the operations processes in your organization.

    To know more about the topic with the help of a real life case, watch the replay of a recent webcast which IBM in partnership with devopsy.kinsta.cloud hosted with Canada Mortgage Housing Corporation’s Jeff Blackadar on how breaking down IT silos helped speed up mainframe development for them.

    Also, do let me know your thoughts on the blog and on the topic.

    1 the born on the web technology teams

    2 http://www.slideshare.net/jedberg/devops-at-netflix-reinvent

    3 http://www.slideshare.net/beamrider9/continuous-deployment-at-etsy-a-tale-of-two-approaches

     

    About the Author/ Mike Fulton

    MikeFaceMedium-150x150A IBM Distinguished Engineer, CTO Enterprise DevOps at IBM,  Mike is a software development professional specializing in compilers, debuggers, profilers and virtual machines. At IBM, Mike works towards understanding and influencing trends and directions in Enterprise IT delivering new technologies into the DevOps Portfolio. He also overlooks integration of the DevOps Portfolio into IBM and Enterprise Software Solutions. Mike is an IBM Master Inventor with several patents to his credit.

    He is an avid blogger and regularly writes on his blog site – makingdevelopersliveseasier.wordpress.com

    linkedintwitter

  • Testing Will Never Be Automated

    Testing Will Never Be Automated

    “Come to think of it, no one speaks of automated programming or manual programming. There is programming, and there is lots of other stuff done by tools. Once a tool is created to do that stuff, it is never called programming again.”

    – James Bach and Michael Bolton, “Testing and Checking Refined

    That’s one of those points that tends to silence a room, as there’s really no way to successfully argue against it, but since similar positions of frustration came up time and time again at the 2015 STAREAST conference, it obviously deserves some further discussion.

    The issue lies in the surprisingly stark differences between the phrases “automated testing” and “test (or testing) automation.” And if you don’t know the difference:

    1. You’re not alone.
    2. You’re likely not a software tester.
    3. You’re discrediting and undervaluing the testing craft.

    The good news is that learning the difference is easy—and testers will forgive you for not knowing it until now! They’re very nice people.

    Here’s what today’s brightest and hardest working testers want you to know. “Test automation applies tools to testing.” They do not automate testing, and they certainly won’t ever replace it. There’s simply no such thing as automated testing.

    And I’m part of the problem. I wrote a column just last year, titled, “Automated testing’s ROI is right under your nose.” I’m somewhat embarrassed that I told the world something that doesn’t even exist provides an immediate ROI—though at least no one went out and bought a completely fictitious tool off of my suggestion.

    Judging by the boisterous cheers as numerous speakers at STAREAST pointed out the absurdity of believing that testing can be automated, this belief is something that I predict testers will likely soon make a concerted effort to erase.

    As companies focus more on collaborative, cross-functional, and quality-minded efforts like agile, test-driven development, and DevOps, testers have an incredible opportunity to clear up any misconceptions about their immense importance to their business.

    Respected tester, author, and public speaker Dorothy Graham recently pointed out a number of these misconceptions in her session, “Blunders in Test Automation” and the very first one on the list was “thinking that testing tools actually do testing.” Sounding almost exasperated at having to point this out, she chuckled, threw her hands up, and said, “They just run stuff, whatever they’ve been programmed to execute, including bad tests.” She almost got a standing ovation.

    When you get that kind of reaction from a room of a thousand software testers from around the world—we’re beyond semantics, and are in a real problem. This is a talented, valuable, and understandably fed-up group of people who are being unfairly cost and productivity-measured against software that provides a completely different service.

    So how did it get this bad, when entire conferences are dotted with calls to action for testers to clearly differentiate themselves from tools, especially when the differentiation is so easy to see?

    One group you may be surprised I’m largely letting off the hook is the tool manufacturers and their marketers. Sure, there are companies that make some claims that testers may wince at, but it’s really hard to find anyone claiming their tool beats, is smarter than, or should replace any human. There’s no reason for them to make these claims; they’re not true, and they certainly won’t help sell the product.

    What about journalists and writers like me who cover the software development and testing industries? After witnessing the frustrations of testers when they feel like they’re being replaced by non-human, non-equivalents—you make a mental note to scratch that phrase from your style guide. I hope other writers do the same.

    How about product owners and others closer to the business side of an organization? Are they contributing to an under-appreciation of the human aspect of software testing? That’s…a little tricky.

    Scott Barber has spent more than fifteen years as a performance tester, but recently experienced (and left) the role of a product owner. While I’m more than familiar with, and a real fan of Scott’s “the truth hurts” speaking style, when he revealed some truths he recently learned, the room grew incredibly uneasy. Many got their first introduction to Scott when he started his session with:

    “It’s not all about testing, you know. Testing is not a product. You are not a product…. Products are the source of profit. And as a product owner, I paid very little attention to testers and testing.”

    It may sting, but it’s the truth. Scott went on to point out that “there’s no need for certain job titles to know or care how things are built or tested. Nobody will ever ask them that.” However, by testers working to gain a much better understanding of the product and the risks that each release candidate poses, there is a massive opportunity to make the value of their work blindingly obvious and positively revenue-impactful.

    Scott’s pro-tip of testers asking a product owner, “Can I do some work with dev and prod so we can get some early observation going on to catch some of these bugs early and head off some of the damage that could come?” drew both a hushed “Wowwww” and “Yeah, I’m using that” from behind me.

    This is where the differentiation between testers and their tools should become clear to everyone. The human levels of empathy, ingenuity, and proactive approach cannot be scripted, automated or baked into any tool, and the best testers care enough about their product and its customers to prove it.

    About the Author/Noel Wurst

    noel wurstNoel Wurst, managing editor at Skytap, Noel is responsible for setting and executing Skytap’s content marketing strategy. That includes overseeing the creation and distribution of high-quality, targeted content, and managing the team and external resources associated with those efforts. By leveraging deep online marketing, project management, and editorial experience, Noel plays a crucial role in helping generate and nurture leads with compelling content.

     Follow Noel on Twitter, @NoelWurst, along with Skytap, @Skytap.

  • Webinar: Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud

    Webinar: Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud

    You may already have a good understanding of the hybrid cloud and its benefits. But how do you get the value of the last three decades of investment in your backend infrastructure into the hands of your end users faster?

    In this webcast we will demonstrate how you can take advantage of the latest IBM technologies to quickly and easily incorporate your backend services into your mobile applications running on IBM Bluemix. We will also highlight the latest capabilities of IBM DevOps Services (IDS) and IBM Bluemix that support the end-to-end mobile development lifecycle.

    Join Kristal York, Executive Mobile Strategist, PointSource an IBM Business Partner and Rosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps as they take you on an in-depth tour of the IBM DevOps Services and Bluemix, an open-standard, cloud-based platform for building, managing and running mobile apps that connect with your back-end services securely.

     


    Recorded Thursday, June 25, 2015

    VIDEO

    SLIDES

    [seoslides embed_id=”2e765888697b” script_src=”https://devopsy.kinsta.cloud/embed-script/build-test-and-deploy-mobile-apps-with-back-end-mainframe-services-securely-in-a-hybrid-cloud/7999/” overview_src=”https://devopsy.kinsta.cloud/slides/build-test-and-deploy-mobile-apps-with-back-end-mainframe-services-securely-in-a-hybrid-cloud/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud” /]


    Your Host:

    alan_new_head_shot Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

    About Panelists:

    kelly-ibm-devops

    Kristal York, Executive Mobile Strategist, PointSource an IBM Business Partner

    Kristal joined PointSource in 2012 and has led teams in the financial, retail and insurance verticals. She excels at fostering a collaborative environment and leading others to solve complex business problems.  Kristal’s prior experience as a business analyst has helped as a mobile strategist to define and analyze our customer’s mobile moments. She translates those mobile moments into a mobile strategy across the organization’s business processes and systems.  Mobile demands an iterative approach so Kristal helps analyze strategic planning, usability, research, as well as consistent updating.  She uses her business analytics skills to help define adoption rates and sentiment analysis once the app is launched.  Previously, Kristal was at Cartus for 12 years, most recently Senior Business Analyst, Business Analytics and Mobile Product Owner.

    RosalindRosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps, Member of the Academy of Technology

    A Distinguished Engineer within the IBM organization, Rosalind is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture; this includes System z and Power system.

     

     

     

     

  • Jenkins User Conference and CD Summit: Calling all London DevOps

    Jenkins User Conference and CD Summit: Calling all London DevOps

    I wanted to give a quick shout out to the large, vibrant and supportive London DevOps community. Later this month (June 23rd and 24th), there will be a joint conference at the Hilton Metropole, London. Combining the Jenkins User Conference and Cloudbees CD Summit, it is two days of CD/CI/DevOps learning.

    Speakers include:

    Kurt Bittner, Principal Analyst Forrester,

    Martin Croker, Managing Director, DevOps, Accenture,

    Sanjeev Sharma, CTO, DevOps Technical Sales & Adoption, IBM Distinguished Engineer, IBM,

    Viktor Clerc, Product Manager, XebiaLabs

    and more.

    The Jenkins User Conference (JUC) features another great lineup of speakers as well.  devopsy.kinsta.cloud as well as a host of others are sponsoring the event.

    In speaking to my friends at Cloudbees they mentioned that there were tickets still available. I found that hard to believe as I know what the community is like here in London.  So if you are going to be in town on the 23rd and 24th, don’t miss this event!  I will be there hosting a great panel on the 23rd as well.

    The Jenkins community is one of the most active that I have ever seen. I am looking forward to seeing many of you in London on the 23rd ad 24th.

    There are still sponsorships for CD Summit as well.  If interested you can contact Cloudbees for info.

    Also this Thursday is DevOps Connect: Rugged DevOps @Infosecurity Europe all day. Registration is free, so come down for a great day of DevOps tracks!

  • DevOps, Containers and Faster Time-to-Parity

    DevOps, Containers and Faster Time-to-Parity

    DevOps discussions often focus on the value of getting innovative applications to market quickly. And it’s true. Getting a cool new application into production quickly can help you differentiate yourself in today’s app-sensitive marketplace.

    But, in reality, most development is devoted to “Me Too” applications—and these apps are no less important to the business than the much rarer innovative ones.

    In fact, as ironic as it may seem, consistently rapid time-to-parity may be more important to the business than occasionally rapid time-to-innovation.

    The Power of “Me Too”
    Every marketer and salesperson knows the power of “Me Too.” Yes, in competitive markets, it’s good to have something the other guy doesn’t. But that differentiation can be for naught if the other guy also has something you don’t.

    Conversely, you can quickly neutralize any advantages your competitors gain by simply replicating them ASAP.

    That’s why ….

     

    –THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–


     

     

    About the Author/Aruna Ravichandran

    ravichandran arunaAruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is  on twitter @aruna13 and on Linked in

  • Budgeting for DevOps Success

    Budgeting for DevOps Success

    One concept that seems to be universal across all IT departments is the admins lament of “how do I convince my boss that we should spend the money.”  Whether it is security, QA or development tools, technical professionals have a difficult time talking the language of the business to justify the expenditure of always scarce dollars. So why should it be any different with DevOps?

    The good news is that in DevOps unlike some other IT disciplines we can actually show some ROI (sometimes anyway).  Nothing will convince a financial stakeholder that spending money is OK faster than if you can show it will allow the organization to either save money or make more money. But how do you show ROI with DevOps. There is more than one way to skin that cat.

    This coming week I am hosting a webinar that will explore the various ways of showing ROI using DevOps.  We will also be looking at some case studies where ROI was demonstrated successfully. One of these organizations is HM Health Solutions. One of the interesting things in this case is that as a health care related organizations the usual compliance issues such as HIPAA often make things like automation and continuous delivery more complex.

    I will be joined by Valerie Scott, Manager of Shared Services Division, HM Health Solutions who is going to relay first hand what she and her team have done to show their executive team how DevOps delivers a real, tangible and measurable ROI.  Valerie is a seasoned exec and I am sure she will have some great insights.

    In addition to Valerie I will also be joined by Rick Slade of IBM who has lots of experience with different organizations in showing the ROI of DevOps.  I expect this webinar to be very informative.  If you are grappling with how to justify a shift to DevOps in your organization I invite you to join us next Tuesday, June 2nd.

    This webinar is sponsored by IBM. It is the third in the series we are doing on Variable Speed DevOps. Our previous webinars in this series have all been very interesting. You can listen and follow along to those here and here. The series deals with how organizations can do more faster  even though not parts of the stack run at different speeds. It is not how fast they run individually, but how well they work together is the key.

    So join me Tuesday as we discuss DevOps ROI and Variable Speed DevOps.

  • 5 Steps for Black Friday, Cyber Monday and Holiday Readiness

    5 Steps for Black Friday, Cyber Monday and Holiday Readiness

     5 Steps for Black Friday, Cyber Monday and Holiday Readiness

    Ho. Ho. Ho. It’s that time of year again. Seriously. It is.

    It’s too late for April Fools but it’s definitely not too early for Holiday ecommerce readiness planning. In fact now is the perfect time to get your ecommerce house in order well before the planned lockdowns of your critical web based applications.

    Balance is important in any holiday ecommerce planning. On the one hand, you obviously couldn’t and shouldn’t make too many significant changes to your ecommerce environment too far into November. But you also need to actively seek out and evaluate new processes and new tools that will improve your customers’ and your employer’s experience during the upcoming holiday season. Making too many or too few changes can land you in hot water. So for starters, perhaps we can agree that a reasonable goal is to avoid earning hall of shame status at http://www.isitdownrightnow.com/

    Christmas Downtime can have multiple root causes but can often be traced back to

     

    1)      Sins of Omission: Lack of proper planning for the anticipated burst in traffic on Black Friday, Cyber Monday and the entire holiday season and

    2)      Sins of Commission: Really frustrating situations where you were trying to upgrade, trying to improve, trying to modernize but sure enough, “changing this breaks that”. You don’t want to spend the holidays remediating one problem after another. Do you?

    Rudolph the Remediation Reindeer from OrcaConfig

     

    The focus of the remainder of this article is to help you with the latter – those seemingly innocuous, “routine” changes to your ecommerce app and all of the related apps, databases and configurations in your ecommerce ecosystem.

    So what’s a DevOps team to do?

    Life is tough enough dealing with “unknown unknowns.” Let’s not make it any tougher by failing to plan for the “known unknowns”. So here are a few keys that we have picked up over years working with e-tailers and retailers who prioritize Christmas ecommerce:

    1. Blackout Periods: Make sure your automation tools know you’re in a blackout period. Whether you use homegrown tools, commercial automation tools, or a combination thereof, users should not be allowed start automated jobs against Production systems during the holiday blackout without approval.
    2. Role Based Access: If your automation tools don’t support blackout periods (and probably even if they do), now is the time to double check that the role based permissions in each tool are set up correctly and adhere to your organization’s guidelines. The most well intentioned engineer can accidentally select Production as a target environment for an automated job, and if they have permission to do so, it can cause an accidental catastrophe during a business critical time.
    3. Restrict Direct Access: Most organizations have an initiative to lock down all their Production servers from direct access, and if you don’t it’s time to add it to the docket. An engineer logging directly into a server to make a seemingly innocuous configuration change to one application can easily bring down another application in the process. Now not only do you have an outage, you have no way of knowing why the outage occurred and who caused it.
    4. Monitor Changes, Not Just Performance: Don’t just monitor the performance of your Production systems, monitor everything you possibly can including configuration changes. Especially if your engineers still have direct access to Production systems, it is imperative you have the tools and processes in place to monitor for configuration changes to the environment.
    5. Experiment Now, Well Before Show Time: All year you’ve been going to conferences, chatting with your colleagues, and in general hearing about all the new tools you should try out. Now is the time to do it! Plenty of vendors offer free trials of their solutions. Some even offer free, full featured trials (ahem). Make good use of your time now by evaluating new time-saving, error-proofing solutions before the calendar catches up with you.
  • What’s hot with DevOps

    What’s hot with DevOps

    DevOps as a movement to transform people, technology, processes for higher business value is here to stay. It’s disrupting organizational processes replacing the old with the new. Command and control IT, a historical approach to regulating tech top-down, is trending toward decentralization thanks to DevOps.

    Software source control is another such case. We saw Git take on the source control bigwigs and redefine how we collaborate and build software. Now, which other areas is DevOps disrupting?

    What’s hot with DevOps?

    Application services

    We have a famous saying in my home country Spain, The King is dead, long live The King! I say, “The application is dead, long live the application.” I’m referring to the practice of implementing applications as monoliths. Monolithic applications are a dying concept. Why? Because it’s better to design them as a collection of services that link together. Such a flexible structure allows service reuse and control at a granular level. And you manage their lifecycles independently. Attempting to control these services centrally though is the equivalent of trying to balance the federal budget.

    It’s challenging to manage the lifecycle of services because of the very nature of agile business decision-making. Since services are much more granular, managing their lifecycle is also such. That’s why current application lifecycle management tools do not scale for service-oriented applications. Next generation application lifecycle management requires a focus on the service not on the application.

    Microservices and Docker

    Microservices is to infrastructure what service-oriented architecture (SOA) is to applications. Next generation applications require agile infrastructure to sustain the cadence of faster releases. Microservices align infrastructure management to the much more granular world of application services.

    Over the last year, microservices gained traction fueled by the container revolution. The unit of infrastructure shrank from a VM to a container allowing applications to run as a composition of smaller self-contained services making application releases that much more agile. So my second bet is on containerizing application services.

    Hybrid and multi-cloud

    Third, cloud infrastructure management tools must scale to the next generation of the container and service-ready applications. In the world where infrastructure is a service, application architecture can no longer rely on infrastructure implementing a particular way. A development or QA environment does not have the same SLA needs or constraints of a production environment as an example. So applications must be able to run across a diverse infrastructure.

    The first generation cloud management tools focused on managing servers in public clouds. That focus made every infrastructure provider a special case. Special cases don’t scale though. The cloud management tools must scale by removing dependencies between applications and infrastructure. Thereby, infrastructure becomes a choice, not a dependency. Application services must be able to run in private, public, hybrid, or multiple cloud environments. Such elasticity and independence are what applications demand from infrastructure.

    Having been in this space for more than a decade now, I live and experience these DevOps trends daily. What are your thoughts, are there any trends you’re following closely?

  • Does Microsoft really have a DevOps story?

    Does Microsoft really have a DevOps story?

    I normally am not a fan of Microsoft conferences. But i’ve always loved the Build Conference. Not just because there is usually an awesome show giveaway. Like this years HP spectre x360, currently my Windows 10 testing machine. But also because the vibe, format, and topic matter is always interesting. I attended this year for the third time, and I wanted to answer the same question I have every year. What, if anything, does Microsoft have for DevOps?

    (more…)