devopsy.kinsta.cloud

Category: Features

  • Continuous Delivery versus Continuous Deploy

    Continuous Delivery versus Continuous Deploy

    Getting a solid grasp on the meaning of DevOps requires a clear understanding of the terms used to describe it. Over the last several years, we have seen a paradigm shift in the way software is developed, moving away from a waterfall approach, with monolithic releases, to an agile approach with incremental releases.   This shift has changed the way in which the Application Lifecycle (ALM) is managed. Focus around what we normally would refer to as ALM is now more accurately described as Continuous Delivery. Continuous Delivery is not a set of tools, it is an emphasis on people (culture), tools and processes. The change from ALM to Continuous Delivery includes three very basic principles:

    • The software is always deployable which means you prioritize keeping the software deployable over adding new features. To do this requires smaller, less risky changes released overtime instead of all at once.
    • A feedback loop of the build, test and deploy steps expose the readiness of the software allowing anyone from development, test or production to determine that an immediate release of the software to any environment can be approved.
    • Automation of the build, test and deploy process is critical in order for the process to be repeatable and to support a higher frequency of builds, deploys and test cycles.

    So like ALM, there is an awareness of a lifecycle (Dev, Test, Prod). But unlike ALM the lifecycle should not be seen as linear. With Continuous Delivery, a software update may move from Development directly to Production without having entered the Test phase. Because Continuous Delivery principles support keeping the software in a deployable state, with a visible feedback loop to determine the readiness of the software, software can be confidently moved into any environment at any time.

    This change between a linear, waterfall approach, to an non-linear agile approach is far more realistic in the way organizations manage their software. Over the course of my 20+ years’ experience working with both large complex enterprises and small software teams, the need to be able to perform a release, into any environment at the ‘drop of a hat’ has been consistent and problematic. The principles behind Continuous Delivery defines a more realistic approach to software development.

    Moving from a linear application lifecycle approach to Continuous Delivery includes making changes at many levels. First, developers must begin embracing Agile practices, managing smaller, incremental releases. Because Agile increases the frequency of builds, testing and deployments, DevOps tools must be in place to support the automation of these tasks. In the waterfall approach, teams had the luxury of time to get build scripts to work, execute test manually, and write a deploy script for every environment. Continuous Delivery does not offer that luxury therefore automation of these tasks becomes critical. This is why Continuous Build, Continuous Deploy and Continuous Test tools are implemented. Continuous Build addresses the frequent building of code changes, updating binaries upon a check-into version control, and reporting on what artifacts were impacted providing feedback into the readiness of the build.

    Continuous Deployment automates the movement of those binaries to any endpoint in any environment and supports server configuration management, all performed on an incremental basis with feedback showing the inventory and the changes. Continuous Test automates testing so developers and/or testers can run through critical functional test, and code analysis to provide feedback on the readiness of those binaries.

    To maximize on automation, these steps are chained together using the workflow engine of the Continuous Integration Server. The workflow can be triggered upon a source code check-in, kicking off a compile/link (build), running code analysis, deploying to an endpoint and running test. In Continuous Delivery, each environment may have their own Continuous Integration workflow that performs the steps needed. For example, a Production CI workflow may just perform activities related to moving the code to hundreds or thousands of endpoints, with database updated, but not execute a build or test.

    Not all is perfect in the Continuous Delivery approach. Automation continues to be a bottleneck. As with most paradigm shifts, changes in behavior and adoption is a major hurdle. In most companies, the use of manual scripts to perform builds, deployments, test automation and manage infrastructure are still called under the covers of the Continuous Integration workflow. These are the same scripts that were used in the waterfall approach, except now there is not the luxury of time to fix the scripts or update them to adjust to software changes. To support Continuous Delivery, the build, deploy, test activities must be elastic, automatically adjusting to code changes, database updates and server configurations.

    To create a more dynamic Continuous Delivery process, DevOps tools are moving away from the need for coding one-off scripts and instead moving to a model driven approach with Playbooks and Plug-ins. Many developers still hold on to these scripts with the argument that they do not want to be at the mercy of a ‘vendor’ or ‘tool’ to manage these low level tasks. As Continuous Delivery pushes the frequency of releases, this final paradigm shift, moving away from the old approach to one-off scripting, will need to move into full automation. Continuous Build will be supported by Build Automation, Continuous Deploy will be supported by Application Release Automation and Continuous Test will be supported by Testing Automation and Virtualization. The automation tool chain will be orchestrated via a Continuous Integration Server and the entire process will become a reliable and fast Continuous Delivery process.

    About the Author/Tracy Ragan

    tracy-clr-128x124pixelsMs. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that was common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

  • APM Prepares Prep Sportswear for Promising Growth

    APM Prepares Prep Sportswear for Promising Growth

    Prep Sportswear kicked off in 2003 and appeared either in the Inc. 500 or Inc. 5000 list of fastest-growing private U.S. companies six years in a row, from 2009- 2014, according to online data from Inc. Magazine. The custom sportswear vendor has achieved 130-percent growth over the past three years, says Mike Jones, Director of Technology, Prep Sportswear.

    Prep Sportswear clothes more than 200K US schools including most middle schools and high schools with custom-printed sportswear for their school sports teams. Prep Sportswear maintains a catalog of each school’s logos so that teams can create their own shirt or jersey representing that institution and team using its colors and logo or mascot. “So you can create a jersey and for me it would be for the class of 1986, Lake Washington High School, and you would see that Kangaroo on the back or on the front,” says Jones.

    The custom-printed sportswear firm serves local teams not affiliated with schools as well as golf courses, colleges, and religious groups. Each customer gets its own store, and Prep Sportswear now maintains more than 2M stores.

    Prep Sportswear: Small Team, Big Technology Play

    Prep Sportswear produces its own sports goods and maintains manufacturing and attendant technologies while also serving ties to firms such as Active Network and others that use its API.

    “We support retail customers, consumers, and our own plants and equipment. On the technology side, we do that with a very small team of ten people. They cover the e-commerce site, our API, and manufacturing needs,” says Jones.

    Prep Sportswear programs its codebase and platform using C# and .NET. It also provides for manufacturing components such as ink and vinyl printers and embroidery hardware. Prep Sportswear manages its supply-chain and its related processes and mechanics. “We do it all in-house despite the fact that it is such a large system with a number of components,” says Jones.

    How Prep Propped Up DevOps

    When Michael Jones arrived at the company, the CTO was deploying releases directly to production from his laptop. “We didn’t have a DevOps team really until Richard came on board,” says Jones, speaking of his colleague Richard Dominguez, Developer in Operations, Prep Sportswear; “before that we were running in start-up mode, just kind of out of a garage until recently.” Richard describes the technical setting when he came on board.

    “A lot of the automation they had was not really automation but little scripts that they ran individually,” says Richard Dominguez, Developer in Operations, Prep Sportswear; “when we released something, we had no idea whether it would break.” At the time, there were few tests on software and there were no external tests at all.

    The Arrival of Change

    With Richard at hand, Prep Sportswear ultimately adopted TeamCity for CI for deploying to its test and production development stages.

    The company also added the Selenium browser-based test suite, coded in Java to run the user-based interactions to determine what the user experience is like. “It checks to see that the page and elements load properly when a user clicks a link,” explains Dominguez.

    Richard found Dynatrace installed when he arrived but not in use. He revived it as the main APM for front-end monitoring. “We also use another tool a lot for our internal monitoring of infrastructure on the back-end and that tool is PRTG,” says Dominguez.

    DevOps Done Right Brings Cheers from the Sidelines

    The combined revenue from all channels last year was about $23M, says Jones. “Since Richard came on, we’ve seen a decrease in time to resolution of more than 50-percent just by having the APM and other tools,” says Jones, with reference to Richard’s revival of Dynatrace and addition of the other aforementioned tools.

    Up times have improved by .50-percent as well. “That stems from simply being able to find an issue and resolve it faster. For an e-commerce site where we don’t have any sales people, it’s just the website, that additional up time is very important to us,” says Jones.

  • The DevOps Dozen

    The DevOps Dozen

    After over 2500 votes cast in the final round and almost 5000 votes in total we are very proud to present the winners of the inaugural DevOps Dozen awards. These companies were voted by you our readers as the top companies in the DevOps market. They are not companies that are necessarily using Devops internally (though many of them are and have had their own DevOps journeys).  They are the companies/organizations who are producing the tools and services that are helping make DevOps the force for change that it is.

    Also a quick word about all of the companies that we nominated for these awards. There were originally something like 100 companies to choose from. We then narrowed it down to the final 32.  Any one of the final 32 were worthy of being in this list. of the DevOps Dozen  At some point yes it is a popularity contest. Some companies are better at turning out their voters then others (just like in real elections).  But on the other hand there were some companies that didn’t campaign at all.  They are here because by consensus they belong here.  With so many votes cast, you have to believe that  the companies that made the final 12 do belong here.

    Congrats to the 12 companies/organizations listed below!

    (Please note that you can download

    [seoslides embed_id=”0e545f934454″ script_src=”https://devopsy.kinsta.cloud/embed-script/dd-finalists-final/10755/” overview_src=”https://devopsy.kinsta.cloud/slides/dd-finalists-final/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”DD Finalists Final” /]

    In the coming months we will hold additional DevOps Dozen awards for companies that are leveraging DevOps most successfully and for those individuals who are the current leaders of the DevOps movement. Stay tuned for those after the first of the year.

  • 7 Sets Of DevOps Success Metrics From DOES ‘15

    7 Sets Of DevOps Success Metrics From DOES ‘15

    Beyond the moral support, the executive management coaching and the tips on how to build DevOps momentum in the enterprise environment, last week’s DevOps Enterprise Summit 2015 offered a boatload of excellent fodder for those seeking to prove the value of DevOps patterns once they got back home.

    DOES wasn’t just about cheerleading—alongside lessons on the soft, squishy elements of transforming IT, nearly every speaker offered up stone cold numbers to back up why those transformations make business sense. The performance metrics shared by speakers were impressive and could go a long way toward swaying skeptical stakeholders. Here are some of the highlights.

    Ticketmaster

    Ticketmaster CTO Jody Mulkey offered a ton of excellent examples of how an organization-wide commitment to DevOps has fueled innovation and stability at his company. For example, he described how what Ticketmaster calls the ‘Boom Team’ has used a completely integrated team of devs, operations, QA and other staff of about 20 to shift its Ticketmaster.com property—which accounts for 40 percent of the company’s revenue—from a duct-tape and bubblegum affair with 2000 ModPerl at its base into a modernized system continuously delivered by that team. Similarly, its technical operations team has embraced the DevOps ethos in order to deliver what it calls ‘support at the edge’ for WebOps incidents. The success of this approach has resulted in:

    • 90 percent reduction in mean time to repair (MTTR)
    • MTTR from 47 minutes down to 3.8 minutes

    “This was a phenomenal change,” Mulkey says. “The business went crazy over this. These are measurable outcomes that have really helped demonstrate that we are making progress.”

    Target

    Target brought forward speakers to discuss the retailer’s innovation in a number of key areas. Heather Mickman, director at Target, talked about how her API team worked hard to not only easily expose product and store information via its APIs, but to also challenge itself in the way it was delivering its work.

    “We wanted to deliver new capabilities in days and not months,” she explains, saying the team needed to be sure that it could scale its APIs because it new that they would be highly reused—both internally and by partners. Target has:

    • more than 90 APIs
    • monthly volume of calls to these APIs have grown in one year from 1.5 billion to 17 billion
    • deploy 80x per week across stage and production enviornments
    • all that, with fewer than 10 incidents per month
    • this volume helped support in 2014 a 42 percent increase in guest traffic and 280,000 orders fulfilled on Black Friday alone

    HP

    HP CIO Ralph Loura says HP didn’t go for the big bang approach, but through careful pilots and the use of communication afforded by ChatOps infrastructure, his team has been able to drag HP IT slowly into the DevOps fray. That’s a good thing, considering the massive scale of the organization:

    • 7,000 developer and operations staff
    • handling over 20,000 change requests per year
    • supporting 1,400 apps
    • and 1000s of builds per day

    CapitalOne

    After four years of hard work to move toward DevOps and continuous delivery, CapitalOne Product Manager Tapabrata Pal had a number of impressive statistics to share on its its progress:

    • Code commits have moved from random occurrence to hundreds per day for any given product team
    • Integration has moved from 1 per day to every 15 minutes
    • QA performance has shifted from monthly to four times per day
    • Production releases have moved from quarterly to one per sprint
    • Defects have been reduced by approximately 60 percent
    • Feature delivery rate has increased by approximately 50 percent

    CSC

    Paula Thrasher, application delivery lead with CSC, stepped up in front of the DOES audience to show them how it is possible to battle bureaucracy at any organization—coming from the government sector, she has first hand knowledge of what it takes. In one example she shared, her organization helped a client move its cyclew time from automating deployments to staging:

    • from 12 hours down to just 12 minutes and 30 seconds.

    IBM

    IBM’s Angel Diaz, VP of cloud architecture and technology, talked about how enterprises can still innovate at the pace of startups while delivering at scale. The thing with IBM is that it puts its money where its mouth is when it comes to DevOps—the company has doubled down to not only offer a number of products viable for the continuous delivery pipeline but to also completely transform its own business through DevOps practices. Some of the results it has seen by shifting its 2,000-plus developers and 100-plus squads in the Cloud Services division to DevOps:

    • 300 percent increase in “pure coding time” for its Cloud Services developers
    • reduction of deployment time from 32 hours down at first to 6 hours and now to minutes
    • an increase of release frequency from months to every three weeks.

    Disney

    Disney’s Jason Cox, director of systems engineering, got the crowd pumped up with a slick mash-up video of Star devWars and DevOps themes (not to mention a private showing of the most recent Star Wars trailer at the end of his talk!). But he didn’t favor style over substance. In his talk he described how much success Disney has grabbed up through DevOps, including:

    • 75 percent reduction manual steps
    • reduction in deployment time for large online/digital experience systems from 3 hours to 20 minutes
    • ability to provision 300-700 srvers within 15 to 30 minutes
  • Devops Days Silicon Valley, you don’t want to miss it

    Devops Days Silicon Valley, you don’t want to miss it

    DevOps Days have become a global phenomenon. These are unique, community-organized events that bring together development and operations practitioners for two days of scheduled presentations, open spaces (more about that later), and networking.

    How instrumental to the DevOps movement are DevOps Days? “DevOps” actually got its name from the discussions that happened at the first DevOps Days organized by Patrick Debois in 2009 in Ghent, Belgium.

    The 6th annual DevOps Days Silicon Valley is happening on November 6th and 7th at the world-famous Computer History Museum. Silicon Valley is the oldest of the US events and was originally the third DevOps Days ever. Starting as a low-key event hosted on the campus of Linked-in in 2010, DevOps Days Silicon Valley has grown into a major event.

    True to past reputation, this year’s speaker lineup blends industry favorites, like John Willis, with a unique mix of soon to be well-known speakers who have been selected by the community. The 2015 line-up includes:

    • State of the DevOps Union by John Willis
    • Anomaly Detection 101 by Elizabeth A. Nichols
    • Not Everybody is Kelsey Hightower by Gregory Poirier
    • Securing the Heart of Automated Infrastructure by Jamesha Fisher
    • Caching Versioned MetaData with Git by Kirsten Hunter
    • Flaming Poo and the Human Response by Jason Hand
    • DevOps Army of One – How to Survive When You’re the SPoF by Jonathan Disher
    • Single Point of Failure… Expert by Sasha Rosenbaum

    But that’s not all! Unlike most conferences where the scheduled speakers are the main event, at DevOps Days, facilitating the interaction between attendees is the main event. Both afternoons are dedicated to Open Space, where the agenda is dedicated to small-group participant-lead discussion and the discussion topics are chosen on the fly each day. This is the chance to dive into specific topics, ask for help, discuss what you’ve done, find like-minds, or just be a fly on the wall and take it all in.

    The DevOps Days experience is one that is unique among technology events — from the local community driven organizing (each one is totally run by local volunteer organizers) to the 50% of time dedicated to Open Space discussions. The whole point behind DevOps Days is to push those with fresh knowledge and insights, no matter how small, into direct contact with those who can benefit from or add to it.

    Of course there is a good bit of fun involved as well. Evening events, ignite talks, and the seemingly cult-like status of the locally designed t-shirts all add to the unique flavor of a DevOps Days event. Austin 2015 was famous for their dueling social themes of Star Wars (May 4th / “May the Force” day) and Cinco de Mayo (complete with large Mariachi band).

    If you are in the San Francisco Bay / Silicon Valley area, get your tickets for the November 6th and 7th DevOps Days Silicon Valley ($150) before they sellout. If you live elsewhere, be sure to keep an eye on the main DevOps Days site for upcoming events. You can also watch presentations from past events on the DevOps Days video site.

    About the Author/Damon Edwards

    41368124db43a27257c31df174a61357_400x400Damon Edwards is the co-founder and managing partner of the DTO Solutions, a DevOps and automation engineering consultancy whose clients include leading SaaS, e-commerce, gaming, and financial services companies. Damon Edwards is also the co-founder and vice president of SimplifyOps, a provider of support and services for the users of the Rundeck open source project. Damon has spent over 14 years working on both the technology and business ends of IT operations. Damon is also a frequent conference speaker and writer who focuses on DevOps and operations improvement topics. Damon is active in the international DevOps community, including co-organizing the DevOps Days conference series, co-hosting the DevOps Cafe podcast, and a co-author of the upcoming DevOps Cookbook from IT Revolution Press.

  • PicsArt’s APM Transition Brings Clarity for Customers

    PicsArt’s APM Transition Brings Clarity for Customers

    PicsArt’s Technology Landscape

    PicsArt enables its creative user base to freely upload or draw, edit, and exchange digital images in a worldwide, web-based community. PicsArt works on the web and on Android, iOS, and Windows Phone platforms.

    PicsArt applies state-of-the-art backend infrastructure to provide its editing applications and social reach for its community. PicsArt uses popular DevOps technologies such as the MongoDB database, the Node.JS JavaScript runtime, and the Redis in-memory data tool. With a foundation of these tools and infrastructure, PicsArt builds and supports apps that avail its users of many free options for creating and appreciating original digital art.

    According to Mikayel Vardanyan, Chief Technology Officer, PicsArt, PicsArt apps and technologies process millions of user requests each day. “We will also soon provide a public API to all of our developers, giving them an opportunity to use our backend services to create their own apps,” says Vardanyan. Though this will satisfy customer requests for additional functionality, it will also further multiply the intricacies of the PicsArt systems, making it ever more critical that they perform properly from foundation to pinnacle.

    PicsArt Experiences the Same Pitfalls as Other Tech Firms, and Responds

    As with any technological system, PicsArt’s infrastructure is at risk of downtime, which looms ready to strike the business and to challenge customer satisfaction at any time. Unforeseeable events as well as planned maintenance outages create downtime and are an expected part of the systems lifecycle, even though they are not always welcome.

    But malfunctions and downtime can exacerbate DevOps processes and corrupt and diminish the user experience. Downtime can temporarily take out entire services, ones that customers will definitely notice and miss when they become unavailable. “If, for example, the users cannot upload their pictures, that would certainly be bad for us,” says Vardanyan.

    Sufficient downtime on the PicsArt backend systems could also cause user registrations functions to fail. The backend also supports PicsArt’s community activities such as sharing artwork, liking others’ artwork, and commenting on people’s creations, which could suffer. “We try to prevent downtime by providing redundancy and scalable systems. We properly test our systems on a regular basis,” says Vardanyan.

    “When we start to sense issues such as these, our operations team goes to work immediately to fix what we need to fix. We investigate all the issues we come across and respond by adding more layers of redundancy and scalability,” says Vardanyan.

    PicsArt Sought Picture Perfect Improvements from APM

    PicsArt was looking for increasing visibility into its infrastructure in order to monitor for the aforementioned problems at their very outset, to create alerts on trouble issues and status reports, and to derive metrics about what is happening across the entire infrastructure from nation to nation, and region to region.

    PicsArt knew that it needed extensive monitoring and that the best way to go would be to have that monitoring centralized in a single product. “We needed to monitor the infrastructure 24/7 in order to provide the best possible service for our community,” says Vardanyan; “we needed external as well as internal monitoring and we needed to monitor the user experience”.

    APM Frames Performance Challenges Nicely

    PicsArt currently uses Monitis. At PicsArt, systems are continually wrestling with pressing loads and with load balancing. If systems performance should lag for any reason, the network can take center stage as the weakest link and the strongest bottleneck. “We utilize the different alerting capabilities of Monitis, such as voice calls and SMS, using all the escalation procedures that its notification systems offer, too. We also use Monitis to create custom monitors for certain scripts and for Redis jobs,” says Vardanyan.

    The cloud-based monitoring solution enables the digital art editing and sharing platform provider to leverage views from a number of global vantage points, clarifying transparency into PicsArt infrastructure. “With Monitis, we can check our global CDN locations and find out what location may have an issue. The benefit is that a potentially issue-stricken location does not escape the monitoring routine,” says Vardanyan. The sooner the enterprise sees it, the faster it can fix it.

    The conveniences and efficiencies of dissecting it all inside a single dashboard enable PicsArt to repair the real problems in its DevOps and platform delivery processes without touching anything that is not out of tune.

  • DevOps success is everyone’s responsibility

    DevOps success is everyone’s responsibility

    For organizations with existing hierarchies and processes the shift to a DevOps mindset can be a challenge. The traditional departmental roles and separation of duties is anathema to an efficient DevOps culture. When it comes to DevOps there’s no room for finger-pointing—every team and individual is equally responsible for making sure everything is firing on all cylinders.

    Gene Kim, coauthor of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win and the upcoming DevOps Cookbook, took part in a podcast earlier this year and shared that two-thirds of the DevOps success stories he has seen are actually from established businesses with existing infrastructures and processes as opposed to “greenfield” projects that embrace DevOps from the start. In those situations, the drive to embrace DevOps has to come from somewhere, but in order for DevOps to work the organization has to overcome the urge to place the entire burden for the success or failure of DevOps on that one team or individual.

    There is a reason that the word “culture” plays such a central role in any discussion of DevOps. Without a shift in the mindset of how teams and individuals communicate and collaborate a DevOps initiative isn’t much different than any other IT project in the organization. One team or person can use DevOps tools, but that’s not really a functional implementation of DevOps.

    That doesn’t mean that DevOps is an all-or-nothing game. It’s possible for different departments or elements within a company to embrace DevOps without the whole company jumping on board. There has to be a quorum of sorts, though—a broad enough consensus between teams and individuals to cooperate and collaborate in a different way than how it’s laid out on the company org chart. An important part of that shift is for everyone to accept responsibility for the outcome and work together toward a common goal.

    There’s a phrase that goes something like “When all you have is a hammer, everything looks like a nail.” Developers understandably view the world through the filter of developing. IT operations people look at projects from the perspective of operations. QA looks at things from the point of view of testing and quality assurance. Accounting considers projects from the financial angle. Security personnel tend to focus on the security aspects. You get the idea.

    Kim shared an excerpt of the upcoming DevOps Cookbook with me. In the book Kim talks about the need to move from functional-oriented teams optimized for cost to market-oriented teams optimized for speed. He talks about the challenges and bottlenecks created when some teams or elements are moving at an accelerated pace while others struggle to keep up.

    Part of optimizing for speed is shifting the perception of responsibility. Smaller, market-oriented teams are more agile and can deliver value to customers—both internal and external—while reducing or even eliminating reliance on other teams. Kim explains, “Taken to its extreme, market-oriented teams are responsible for not just feature development, but also testing, securing and deploying their code into production themselves, as well as being responsible production operations and availability.”

    In order for DevOps to work effectively, everyone needs to forget that they’re a “hammer” and view the project as a more comprehensive toolbox instead. DevOps teams need to strive to break out of the traditional roles and silos and make a conscious effort to see things in terms of the common goals or greater good.

  • DevOps Enterprise Summit 2015 kicks off

    DevOps Enterprise Summit 2015 kicks off

    Are you going to San Francisco? If you are you don’t have to wear a flower in your hair. But if you are into DevOps or want to be and are in San Francisco this week you should be at the DevOps Enterprise Summit 2015 (DOES 2015). The conference produced and hosted by Gene Kim’s IT Revolution and Electric Cloud, features a 3 day schedule chocked full of success stories of enterprises who have adopted DevOps.

    Additionally many leading DevOps companies are sponsoring, exhibiting and otherwise participating.  Several are making or touting recent announcements. Electric Cloud themselves have just made a big announcement, releasing ElectricFlow Release which according to the company “helps organizations speed application releases by streamlining and automating software deliveries into highly organized and well-choreographed release pipelines. For software teams adopting DevOps and Continuous Delivery, it replaces checklists and spreadsheets with a single, unified view across both traditional and Continuous Delivery style application releases to increase reliability, transparency and predictability while lowering risk.”

    Screen Shot 2015-10-18 at 10.48.59 PM

    More on this in another post coming this week.

    IBM is making a major announcement as well with the BlueMix Garage Method. I had a chance to speak to Randy Newell about this new release and you can listen and read the transcript of that conversation here. IBM is a major sponsor of DOES and have several sessions and events planned including a DevOps Garage event at the Galvanize building Monday night.

    devopsy.kinsta.cloud will be providing extensive coverage of DOES 2015.  Ericka Chickowski and I will be live blogging from the conference all three days in addition to filing stories to keep our readers up to date.  Additionally we are setting up a video booth in the foyer by the Grand Hall. We are video interviewing every speaker at the conference, as well as select other guests.  Look for those videos to be available soon.

    So if you are at DOES stop by our video set and say hello. If you can’t make it, devopsy.kinsta.cloud will do all we can to keep you up to date on all of the goings on at DOES 2015.

  • Continuous Deployment is king of the DevOps hill

    Continuous Deployment is king of the DevOps hill

    One of the promises of DevOps is continuous deployment. DevOps is, first and foremost, a matter of shifting the traditional business culture more than the tools and technologies that enable it. Once that culture exists, though, one of the defining aspects of DevOps is automation and continuity.

    Earlier this year I wrote about the seeming ubiquity of “continuous” solutions throughout DevOps:

    If DevOps is the buzzword du jour for tech, then continuous is the buzzword du jour of DevOps. Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response…or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.

    Taking a closer look at all of that continuous continuousness, however, continuous deployment stands out as one of the prevailing goals of effective DevOps. Continuous integration, continuous delivery and the other continuous tools and processes are all in some way related to facilitating the flow of continuous deployment or monitoring and managing it after the fact—which ultimately feeds back to the beginning of the loop and back to continuous deployment.

    Chris Riley tried to muddle through the confusion of continuous integration, continuous delivery and continuous deployment. In his explanation of continuous deployment, he stressed the impact of this symbiotic loop that surrounds it: “Continuous deployment has additional costs, as it relies on instrumentation, to ensure that new functionality does not result in bugs and also on infrastructure that allows effortlessly backing out new features when a defect has not been caught by automated tests.”

    I defer to Riley on most things, but I don’t agree with his summation that everyone should do continuous integration, some should do continuous delivery, but only the rare few should strive for continuous deployment.

    I guess it depends on what perspective you’re considering it from. From the standpoint of ease or simplicity and the likelihood that an organization can execute it effectively I can see where Riley is coming from. From the point of view of the goal of embracing DevOps, though, I would reverse his order and say that everyone should do continuous deployment, most should implement continuous delivery to facilitate it, and some (or maybe most as well) should adopt continuous integration to drive continuous delivery.

    The primary objective of DevOps, though, is to deploy apps. Everything else plays a supporting role.

    That said, there is a difference between embracing DevOps with the goal of developing and deploying apps more efficiently and effectively, and adopting continuous deployment tools that automatically pass all changes that pass automated testing and are verified as deployable by continuous delivery tools into production.

    A blog post from Puppet Labs explains, “There are business cases in which IT must wait for a feature to go live, making continuous deployment impractical. While application feature toggles solve many of those cases, they don’t work in every case. The point is to decide whether continuous deployment is right for your company based on business needs — not on IT limitations.”

    There are many acronyms and various interpretations out there for DevOps, so my opinion certainly isn’t gospel on the subject. What do you think? Should continuous deployment be the primary goal and centerpiece of DevOps automation? If not, which of the many “continuous” solutions would you suggest as the central focus?

  • Survey on Modern IT – We Need Your Opinion!

    Survey on Modern IT – We Need Your Opinion!

    Change is the only constant in the world of IT. Developers, ITOps and the DevOps community are undergoing significant changes in needs, processes and services. This survey will provide better understanding of how the latest trends are impacting innovation, security and your team.

    This survey is sponsored by Apcera, a highly secure, policy-driven platform that lets enterprises innovate at speed with full confidence and trust. You can learn more by reading an interview with Apcera CEO, Derek Collison, on Container Journal.

    The survey is under 20 questions and takes about 5 minutes to complete. Share your thoughts on what is leading innovation, what stands in your way and how new technologies are are influencing the IT landscape.

    By taking the survey, you’re helping the entire DevOps community better understand where we stand and where we’re headed. As always, the results will be released when the survey period is complete.

    Take the Survey