devopsy.kinsta.cloud

Category: DevOps Toolbox

  • The Right DevOps Tool for the Job

    The Right DevOps Tool for the Job

    Innovation and environment are only two factors in determining which DevOps tools are best for your organization

    Any time there is a movement in IT that involves a new space and new toolsets, there is sudden growth, then inevitably consolidation and, finally, a selection of tools that suit the needs of most customers. Then the cycle starts over. Usually by this point, users have developed a defense mechanism about their choices regarding which solutions to implement and discussions can get heated.

    I’m happy to say that the last bit—heated discussions—has not occurred with DevOps the way it has with other technologies (think the browser wars, OS dominance or even cloud service provider preferences). There is the occasional “You’re doing it wrong,” but not the wild-eyed flame-wars so far.

    But the other two? Yes, yes indeed. DevOps has been through a couple of cycles, and the end is nowhere in sight. I don’t necessarily see that as a bad thing; in fact, as long as innovation is occurring, you have the opportunity to look at changes and decide what can best help your DevOps efforts.

    My mantra since the language wars was that C, C++, VB, etc., were the “right tools for the job.” I have kept that mantra for all of IT. It is easy to adapt the tools you are familiar with—to do more than they were designed to—and most shops have fallen into this trap at some point. But a serious look at what is available and where the market seems to be evolving usually stops this kind of adaptation.

    Some shops use Jenkins for far more than it was designed for. It’s a great tool, but at some point, the benefits of using tools aimed at a given piece of the DevOps toolchain outweighs the fact that Jenkins could handle that bit.

    The popularity of Puppet is starting to cause the same issues, if anecdotal evidence is to be believed. In words I use to my children, “Just because you can, doesn’t mean you should.”

    The environment always plays a role in the “right tool for the job,” but it should not be the major factor. Having a DevOps tool that you already know that could do the job is one answer—but quite often not the best answer.

    So, use resources like us here at devopsy.kinsta.cloud, and your favorite site for IT ratings and reviews. Do some feature research, think about what it would take to make your existing tools do the same job, and consider bringing in new tools to achieve a given goal. We see so much change these days that sticking with what you know on this one tiny bit of the toolchain, may seem reasonable, but make sure you are not missing out on additional functionality or suitability to task over the long term.

    — Don Macvittie

  • DevOps Market Consolidation Gets Real: CloudBees Acquires Electric Cloud

    DevOps Market Consolidation Gets Real: CloudBees Acquires Electric Cloud

    You may have already seen the news today: CloudBees has acquired Electric Cloud in a move that marks a true market consolidation in the DevOps space. I had a chance to speak with CloudBees CEO Sacha Labourey to discuss the acquisition. We discuss the motivation for the deal, what the combined entity may look like going forward and more. The video of our conversation is at the bottom of this article.

    In my mind, this acquisition represents true consolidation of the DevOps tool vendors market. My reasons for this are as follows:

    1. Until now, many of the acquisitions in the DevOps space have been by large, established public companies such as CA, HP or IBM. Typically, these kinds of deals are not as much consolidation as they are large companies using M&A activity in place of R&D. CloudBees is not a large vendor—this isn’t R&D dressed in an acquisition.
    2. Electric Cloud is not your typical venture-backed startup that is looking for exit opportunities. The company has been around for many years. It has a large base of enterprise customers and an enterprise-tested product.
    3. With the recent changes in the DevOps vendor market involving CA (now Broadcom), HP(E) now Micro Focus and IBM preoccupied with Red Hat, there is a vacuum for enterprise leadership. The combination of these two vendors of scale is really a consolidation move.

    Best of luck going forward and congratulations to our friends at CloudBees and Electric Cloud. It will be interesting to see what repercussions this deal brings to the rest of the DevOps market.

    For more details on the acquisition, check out Mike Vizard’s article in devopsy.kinsta.cloud today. In the meantime, enjoy the video and conversation with Sacha. Also, let us know what you think about the acquisition—and other M&A activity in the DevOps space—in the comments section below.

    — Alan Shimel

  • XebiaLabs Injects Predictive Analytics Into DevOps Platform

    XebiaLabs Injects Predictive Analytics Into DevOps Platform

    XebiaLabs is moving to take the guesswork out of DevOps following the launch of a set of tools that leverage machine learning algorithms to predict when and how the release of an application is most likely to go awry.

    The Risk Prediction Module being added to the XebiaLabs DevOps platform comes on the heels of XebiaLabs’ move to make its XL JetPack software for automating application deployments available on the Amazon Web Services (AWS) Marketplace. XL JetPack is an automation framework based on YAML files and a declarative programming framework that enable DevOps teams to push applications into production on a cloud platform in as little as 15 minutes.

    XebiaLabs CEO Derek Langone said that while DevOps advancements have been made in terms of achieving continuous integration, the goal of achieving continuous delivery has proven to be more elusive. As automation frameworks such as XL JetPack become more accessible, however, IT operations teams will be better able to keep pace with the rate at which organizations want to be to deploy and update applications, he said.

    It’s becoming increasingly apparent that a combination of automation frameworks and machine learning algorithms will enable DevOps teams to make a significant leap forward in terms of application release lifecycle management. Because of all the nuances of the different platforms that IT organizations are trying to leverage, it’s become a major challenge to roll out an application manually. As the number of applications that need to be released at roughly the same time increases, managing the release cycle process is moving beyond the capabilities of an IT team made up of mere mortals.

    The Risk Prediction Model from XebiaLabs promises to increase the odds of success by applying predictive analytics infused with machine learning and other proprietary XebiaLabs algorithms to identify DevOps bottlenecks before they are encountered. Capabilities provided by that module include alerts that warn the team when a release is likely to be delayed or to fail before the release pipeline starts running; a Risk Forecast view that summarizes predicted delays and failures for every task in the release process; an overview of statistics for similar releases to provide historical context; and forensics tools that uncover flaky automated tests, problematic build setups, long-running deployments and time-consuming manual tasks. That Risk Prediction Module is meant to complement the risk scoring capability that XebiaLabs already includes in its platform.

    Arguably, the biggest barrier to DevOps adoption today continues to be the level of expertise required to succeed. But as the combination of predictive analytics infused with machine learning algorithms and algorithms that can discern instantly how changes to the IT environment will impact applications become more common, the level of expertise required to master DevOps processes should decline. As that transition occurs, the number of organizations embracing DevOps more broadly should increase.

    In the meantime, DevOps teams would be well-advised to consider to what degree they might next want to rely on predictive analytics to prescriptively automate processes with eye toward eliminating the need for as much human intervention as possible.

    — Mike Vizard

  • Alerting Consolidation: What’s the DevOps Impact?

    Alerting Consolidation: What’s the DevOps Impact?

    Over the last 12 to 18 months, the monitoring and alerting piece of the DevOps toolchain has been going through some serious consolidation. Companies are bracing to compete with the world or getting picked up by larger DevOps players, making their product more appealing through integrations.

    In general, if such changes don’t impact your toolchain, I say ignore them. The exception is when it appears the entire submarket might need to get aligned to survive, because that means at some point your toolchain likely will be affected.

    So, to recap the source of this blog, in the last short while OpsGenie has become a part of Atlassian, VictorOps has become a part of Splunk and PagerDuty has filed for an IPO. It is likely the rest of the market will have to match these three or admit to eroding market shares. In a competitive market where customers are using a fraction of the available functionality of a given product, deeper integrations (like come from ownership) or bold road maps (like come from IPOs) can have an impact on what customers choose to use.

    Alerting—and monitoring in general—is still relatively new to its current incarnation, and unlike some markets there are still very real differentiators in it. Most alerting engines have a core of functionality built in, while a lot more functionality can be had through integrations with other products. Some focus on the network to garner the bulk of their alert conditions, while others focus on application performance and still more watch the infrastructure closely. While all do a bit of each of these things, they still definitely have a focus. That will change over time as the market either settles down or fragments. I’m hoping it will settle down; we have enough sub-markets in DevOps already.

    All I’m suggesting is that you stay in contact with your vendor of choice and watch the overall market. Some of the changes might create a situation in which an alternative is appealing, and that is worth looking into, but other changes might negatively impact your chosen solution, which is absolutely worth noting.

    If your product of choice is clipping along in a way that is acceptable/useful to you, by all means stay with it. There’s no sense changing a product simply because of possibilities. But being aware can help you navigate the market changes that are well underway and very well might hit you right in the stack.

    — Don Macvittie

  • DevOps and Security: Be Ready to Shield Your Application

    DevOps and Security: Be Ready to Shield Your Application

    All of us have heard of continuous improvement/continuous delivery (CI/CD). There are many benefits to implementing CI/CD, as it helps seamless integration from end to end for development and deployment processes. CI/CD helps in rapid improvement, shorter release cycles and more, but it also helps with the challenge of handling security effectively at DevOps speed.

    Tools for Securing DevOps

    There are thousands of DevOps security tools available in the market that help us at HCL Technologies secure our software development at various stages of the CI/CD pipeline. There are new vulnerabilities rolling out daily, and so we must be alert and keep our applications safe and future-ready.

    These are the DevOps security tools we use (most tools are open source with an option of enterprise edition):

    1. OWASP SonarQube
    2. OWASP ZAP
    3. OWASP Dependency-Check
    4. OWASP Glue
    5. Anchore
    6. Clair-CoreOS
    7. FOSSA
    8. Cyberark Conjur

    Our DevOps Toolchain Diagram

    Securing CI/CD

    Let’s consider a job in which we check out the code from GitLab/GitHub with auto-commit (a Jenkins job will be triggered as soon as the developer makes any changes in the code). You can refer to this link for  more information about Jenkins GitLab automation.

    Now, in Jenkins, we can run a security test and present it in the form of reports and dashboard to meet our needs. To get started, we can use OWASP SonarQube for static analysis. OWASP SonarQube includes found bugs, PMD and several security plugins bundled out of the box. Next, for dynamic analysis and penetration testing, we can use OWASP ZAP, which presents reports in XML/HTML format that can be used to create Jira issues.

    In the above scenario, we can also use ZAP through custom tools integration. In our case, we have installed ZAP on our local machine. We can also use OWASP ZAP installed in a remote machine.

    Steps for Remote OWASP ZAP Connection

    Windows Command: C:Program FilesOWASPZed Attack Proxy>zap.bat -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    Linux Command: Zed Attack Proxy>zap.sh -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    OWASP Configuration in Jenkins

    The reports will be generated in .xml and .html format. Now, with the reports generated by ZAP, we developed a Java program to create Jira issues for every vulnerability detected and assign it to the concerned person.

    Next, we have OWASP Dependency-Check analysis on our project. To configure for Jenkins, follow these steps:

    First, we need the OWASP dependency-check plug-in (which I have already installed). This process may take several minutes, as it downloads from NVD server.

    Here are the next steps:

    Alternatively, we can use the OWASP Glue plug-in, which runs OWASP ZAP, OWASP Dependency-Check and other security automated tests.

    We have also used FOSSA in our projects for license audits and vulnerability management for OS dependencies. We can use FOSSA as on-premises, but it is available only for use on Ubuntu machines.

    At HCL, we are currently working on container security with Anchore and Clair-CoreOS. We have also integrated identity access management (IAM) to our CI/CD jobs. As for IAM, we are working on CyberArk Conjur and HashiCorp Vault.

    CyberArk Conjur

    The Conjur Jenkins credentials plug-in:

    HashiCorp Vault

    Conclusion

    I have worked on various tools for security with DevOps. Below is a quick comparison of the tools that can be used for application security.

    Now that you have an idea of which tools to use, embrace security instead of worrying about it. DevSecOps can help improve and increase the outcome and effectiveness of any organization.

    — Debarghya Pandit

  • Monitoring the DevOps Toolchain

    Monitoring the DevOps Toolchain

    DevOps has grown in popularity among many companies seeking greater agility and higher-quality code. When using different tools for automation, these organizations need monitoring and tracking of these tools and metrics from different portals on a common dashboard. Toolchain monitoring helps to bring all reports into a common portal.

    Enabling monitoring tools from a centralized platform can save a lot of effort and time. These tools have many in-build capabilities that bring value to the business, such as predictive alarming, graphical representation of data and integration with other tools including email, ticketing system and auto remediation. These added features become game-changers in today’s competitive SLA-driven and standard environments.

    Monitoring can be categorized in three ways:

    • Infrastructure monitoring: Monitoring the environment, machine and resources used to create a platform for an application.
    • Application monitoring: Monitoring the application’s performance, resource consumption, processing time and responsiveness.
    • DevOps monitoring: Monitoring the pipeline and toolchain from continuous exploration through release management. DevOps monitoring tools have the capability to monitor job health, job status, performance and quality.

    Why DevOps Monitoring is Essential

    In DevOps, we use many tools to create a toolchain and pipelines. In some big teams with a long release train, monitoring a project’s status from requirements-gathering to deployment can be difficult, as you have to track a number of different tools. And even then, you might not get the status in a desired format. DevOps monitoring tools bring everything to one single dashboard, where you can see the status and other metrics, including useful information about the project quality and progress.

    DevOps Monitoring: Not the Same as Tools Monitoring

    Tools monitoring is specific to the health and performance of tools; DevOps monitoring focuses on things such as the status of sprint, code quality, code branch status, test results and deployment status. All of which are required by project management for continuous improvement in productivity and quality.

    What to Monitor?

    There are a number of things we want to monitor in DevOps orchestration, and all these metrics provide a perspective of the current status of the project or product development and productivity:

    • Performance: Performance of the application.
    • Development (sprint or Kanban progress) and defects status from the application lifecycle management (ALM) tool.
    • Code repository monitoring for a project specific branch.
    • Build job or pipeline monitoring from the continuous integration (CI) tool.
    • Code analysis and security test results and reports.
    • Deployment and upgrade status in different environments.
    • DevOps maturity using the tools’ usage and quality data.
    • Artifacts (versioned artifacts).

    These are the basic and mandatory areas any project would monitor on a single dashboard.

    Monitoring Use Case

    In agile projects, CI/CD tools are implemented following the best practices of DevOps. An ALM tool is implemented to manage the backlog and development sprints. On this project a CI tool is used to build code and all the code is getting committed in a code repo, using a code review and analysis tool. A binary repository has been implemented to store all the binary of every version.  An automated deployment tool is being used to deploy the application in QA, staging and production environment.

    Now the struggle comes when monitoring each tool, the status of the build and the progress on different portals (CI tool, code repo, analysis tool, deployment tool, etc.).

    Using centralized monitoring tools can help project management to monitor the metrics mentioned below. These metrics give the overall picture of build, quality and deployment status on one dashboard.

    Available Tools for DevOps Monitoring

    Below are few available products that provide similar solutions:

    • Hygieia: Freeware tool that supports all DevOps tools, but metrics are very limited.
    • KlipFolio: Has lots of tool support, but it’s not free.
    • DevOps Insights: An IBM tool that supports IBM cloud platform only.
    • DataDog: Has a wide range of tool support, but it’s not free.
    • Prometheus: Freeware tool that monitors lots of tool-using exporters.

    Build vs. Buy

    Deciding which tool to use is always a tough task—you need to compare all the available tools and their offerings from different perspectives. Below are a few factors that play an important role when deciding on available options or to build your own solution:

    • Range of supported tools (plugins or data collectors).
    • Freeware or paid.
    • Support to customize data collection.
    • Rich UI for data representation and customization of fields and views.
    • Range of metrics supported.
    • Ease of installation and configuration.
    • Licensing and distribution policy.

    Solution Approach for Building Your DevOps Monitoring

    If you have decided to build or extend any existing tool, below are some considerations:

    • Identify the tools you have to monitor: List the DevOps tools you have to monitor; the list should cover all the areas of DevOps (build, repo, code quality, deployment, monitoring, etc.) to get the complete picture.
    • Identify the metrics: Once you have the list of tools, identify the important metrics from each tool. Your metrics should be capable of providing KPIs of DevOps areas.
    • Identify API or command-line interface to fetch the metric data: You need a good understanding of tools and their implementation to identify the best way to fetch the data. It could be predefined APIs, REST APIs or any command line interface. Make sure you are getting all the desired data.
    • Correlate the metrics with the business value or define the DevOps KPI: Your metrics should represent the KPIs and business value of all the tools involved in achieving DevOps. The dashboard should cover all the aspects and represent the current status and gaps.
    • Determine how to store and process those metrics: You need to define the schema to store the data in defined database; your schema should be generic enough to cater any data from different tools. To process the data, you need a middleware component between database and UI to process in a presentable format.
    • Build a scoreboard based on metrics: Use a rich GUI to display the scoreboard in different formats such as table, graphs and charts.
    • Support high availability: The tool should be designed to support high availability to avoid downtime and loss of data points.

    How Monitoring Tools Collect Data

    Most of the tools we use for implementing DevOps and CI/CD are web-based tools such as Jenkins, Sonar, Git, SVN, UDeploy, Gerrit, Jira, Confluence or others. These tools provide REST APIs, from which we get the data in a described format—either in json or xml. Some tools support predefined APIs or CLIs to connect and fetch the data. Once you identify the communication mechanism with the end system, the next step will be writing robust code that can fetch the desired metrics data and handle all the cases to parse the data and put it in a relational or non-relational database.

    Once you have the data in the database, you need a GUI to display those in tabular and graphical formats and a middleware component that can fetch the data from the database and provide it to GUI in the desired format.

    Getting the data from the system you want to monitor is the real challenge in this whole exercise, as everything else depends on it. Below are a few challenges you might face while developing a toolchain monitoring system:

    • Identify the API or any other mechanism to fetch the data.
    • Identify the metrics to monitor.
    • Identify how you want the data to be presented on the GUI—whether a trend chart, pie chart or just tabular presentation.
    • Determine the authentication mechanism for the monitoring system, as each supports a different kind. Sometimes it needs a predefined token while other times a token needs to be generated at runtime.

    Simple Architecture of DevOps Pipeline Monitoring

    Below is the simple generic architecture, on which most of the monitoring tools work. In the picture below, the different DevOps tools are on the left side; these tools are the end system from where we want to bring the data. Only a few tools have been shown as an example.

    A data collector brings the data from each end system and communicates with the end system using a REST API or any API exposed by that tool or a CLI, depending on the case. Using the defined communication mechanism, it will bring the data and pass it to the parser to fetch the required data and put it in the database in the desired format.

    While developing data collection, you need to have good a understanding of the tool you are going to monitor as well as available APIs including REST, CLI, SMIs or any pre-defined API built within the tool.

    The data parsing layer will fetch the desired metric value from the raw data collected by the data collector. Raw data could be in any format, including key value pair, json, xml or csv. The parsing methodology will differ in each case depending on the type of data. You can use any generic API for the parsing available.

    You must identify a good API to parse the data available in a different format and complexity.

    The database will hold the metrics data of each interval for each tool and user credentials.

    The GUI will request the data from the parsing component. It will represent it in tabular or graphical user-friendly format.

    Other features: Once we have data, we can have the trend chart to make some critical decisions, we can generate alarm on breaching any defined thresholds and integrate it with email or SMS to take immediate action.

    Monitoring Tool High Availability

    If we are relying on our monitoring tool to get reports of all the tools used in DevOps, we cannot afford downtime. We may lose data points and trends if the monitoring tool goes down, and management may not get the actual status of an entire project without having to gather the data manually.

    To avoid such situation, high availability (HA) should be implemented on the monitoring tool. In case of a HA setup, we will keep gathering the data in case the monitoring node goes down.

    To implement the HA, there are two aspects we need to consider: the HA of GUI and middleware (business logic component) and the HA of database.

    HA in the GUI and middleware could be achieved using an Apache or Nginix cluster. In the case of containerized environments, we can use any orchestration platform’s default feature to achieve high availability, such as Kubernetes. Similarly, in the database we can implement a clustered database feature provided by the most of available databases.

    Conclusion

    DevOps toolchain monitoring is very useful. It provides a good snapshot of the health of a project to management and is able to identify any blocker issues that might impact the release so they can be corrected. Monitoring can help identify pain points to focus on in defining the road map. Organizations following DevOps practices and using DevOps tools should have a tool to monitor the DevOps pipeline.

    — Prateek Kumar Asthana

  • SmartBear Integrates Test Tools with Atlassian DevOps Platforms

    SmartBear Integrates Test Tools with Atlassian DevOps Platforms

    At the Atlassian Summit 2019 conference this week, SmartBear announced it has integrated the Zephyr test automation tools it acquired last year with the Jira portfolio of tools from Atlassian.

    In addition, SmartBear announced it has integrated Zephyr with the rest of the company’s SoapUI Pro, TestComplete, CrossBrowserTesting and LoadNinja testing tools.

    SmartBear committed to integrating its entire portfolio of tools with other Atlassian offerings as well, including the Bitbucket continuous integration/continuous development platform and Confluence content management software.

    In general, SmartBear views efforts to modernize applications using DevOps practices as a primary driver of increased demand for tools to test application programming interfaces (APIs). A recent global survey of 3,000 API developers, architects, testers and product leaders conducted by SmartBear finds nearly three-quarters of respondents believe that adoption of microservice architectures will drive the biggest growth in API adoption in the next two years.

    The biggest challenge faced by well over half the respondents (58%) is finding a way to standardize API development. In pursuit of that goal, the survey finds 69% of survey respondents are now developing APIs that comply with the OpenAPI Specification (OAS). That specification defines a language-agnostic interface to RESTful APIs that enables both humans and computers to discover and understand the capabilities of the service without access to source code or documentation, or having to inspect network traffic.

    The SmartBear survey also finds 76% of respondents say they already have a formal API monitoring process in place and that 76% of organizations are developing both internal and public-facing APIs.

    Daniel Giordano, associate director of product marketing for SmartBear, said these days there’s a lot more focus on trying to make it easier to discover APIs whenever possible by setting up API catalogs. Those catalogs are also now making it easier for organizations to reuse APIs rather than develop new ones for each microservice that gets developed, he added.

    In fact, Giordano noted that many organizations now define the APIs they are going to depend on to integrate their applications long before they begin to write application code. Those APIs are then reviewed by an architecture team to make sure they meet performance requirements while still being flexible enough to evolve consistently with the other APIs the organization needs to maintain, he said.

    Today, organizations make use of many more private APIs than they do public ones. APIs first came into their own as a means to expose applications to enable external applications to consume data from another application as part of the so-called API Economy. Since then, the number of private APIs that organizations rely on to integrate internal applications has exploded. In fact, building and deploying those APIs has become an integral part of any DevOps process.

    Naturally, the relationship between API management and DevOps processes is still evolving. But as DevOps processes within IT organizations continue to mature it’s only a matter of time before they are applied equally to both the applications being developed and the APIs relied on to integrate them.

    — Mike Vizard

  • 5 DevOps Trends Worth Knowing in 2019

    5 DevOps Trends Worth Knowing in 2019

    DevOps today is more than the buzzword it was 10 years ago. Back then, the idea of combining development with production in your IT infrastructure was not common; the logistics were nonexistent and most of the time businesses decided it was far too much effort.

    However, if the last nine years has taught us anything, it’s that DevOps is worth every penny businesses invest. It helps companies streamline production, keep customers happy and provide agile services to attract new audiences.

    But as with anything in the IT field, there is a paradigm of change. This article discusses some of the top DevOps trends happening now and how to implement them in your own system.

    Automation Will Be a Bigger Focus

    Automation has always been the way for businesses. Whether it’s speeding up the pipeline with machines, providing better response times for angry customers with chatbots or better inventory management with tracking and logging system, automation is behind it all.

    DevOps is no exception.

    But as with everything, there can be too much automation. The best thing to do is break down processes and find simple, redundant tasks that can save time if automated and apply the changes.

    The most important aspect of automating DevOps is to understand the six pillars in the DevOps cycle, which are:

    • Continuous business planning
    • Collaborative development
    • Continuous testing
    • Continuous release and deployment
    • Continuous monitoring
    • Collaborative customer feedback and optimization

    DevOps Assembly Lines: The Next Big Thing

     

    To track the development of your application, we have pipelines. These visually represent the product from its initial stage right through until final development and release.

    However, continuous integration (CI) is no longer the priority focus when it comes to effective monitoring and implementation. Continuous delivery and automation are a major part that businesses have already started delving into in 2019.

    This is where DevOps assembly lines enter the picture.

    Assembly lines are focused on bridging the gap between manual and automated tasks, ensuring there is no redundancy while providing several tools for teams to implement, to ensure apps are hitting the production lines as reasonably quickly as possible.

    Microservices Architecture Adoption Taking Off

     

    Microservices architecture may as well be that new kid in school trying to fit in. These smaller services compound into agile, implementable tools that DevOps teams can use to scale and test software over the course of weeks—not years.

    As you can imagine, this can help some businesses streamline their development and production lines, setting them way ahead of their original production estimates—which is never a bad thing.

    Implementing microservices into your DevOps team can also help companies focus on the runtime and efficient delivery of new development sources, without the hassle of creating dependency errors when something decides to bug out for no apparent reason.

    Security Needs to Step Up

    Cybercrime is on the rise—we all know that’s old news. But as a business, cybercrime can either make or break your sales and weigh down your DevOps team.

    That’s why more companies are hopping onto enterprise security options. Although there are third-party programmers for almost every situation you need, none of them have the same security levels as the tools from the enterprise version provides. Safeguarding both your company and your clientele.

    Riding the Artificial Intelligence Wave

    Finally, we have artificial intelligence (AI) and machine learning (ML). When you think about it, these two elements are literally the sum of everything we want in the DevOps community—the ability to crunch out hours upon hours of menial labor and saving your teams hours to focus on higher-priority tasks.

    The combination of AI, used to predict algorithmic influencers, and ML’s ability to adapt to new situations will be key for DevOps teams to get to the next level in 2019.

    — Gil Artmoore

  • Atlassian Integrates DevOps Portfolio

    Atlassian Integrates DevOps Portfolio

    At its Atlassian Summit 2019 conference, Atlassian announced updates to all the DevOps tools that make up Atlassian Data Center as well as upgrades to its Opsgenie incident management software to provide deeper integration with the rest of the company’s portfolio.

    At the same time, Atlassian revealed it has rebranded the AgileCraft business planning application it acquired earlier this year to Jira Agile.

    New capabilities added to Atlassian Data Center include the ability to set up smart mirror farms for Bitbucket Data Center; content delivery network (CDN) support for Jira Software, Confluence, Bitbucket and Jira Service Desk Data Center; rate limiting for Bitbucket, Jira Software and Jira Service Desk Data Center; issue archiving for Jira Software and Jira Service Desk Data Center; templates for deploying on Microsoft Azure and Amazon Web Services public cloud; and a mobile application for Jira Server and Data Center.

    Atlassian Data Center now incorporates Jira Software 8.0, Confluence 7.0, Bitbucket 6.0, Jira Service Desk 4.0 and Portfolio 3.0. The latest version of Jira Software 8.0 now executes advanced searches using Jira Query Language (JQL) 31% faster on average, while agile boards load two times faster and re-indexing times are now 71% faster. The latest version of Confluence adds support for multimedia files and additional analytics tools to the content management platform.

    The Atlassian Cloud service has also been expanded to increase the user limit to 5,000, with an early access program signaling an intention to bring that up to 10,000 users soon.

    Meanwhile, specific capabilities being added to OpsGenie include support for incident timelines to track response activities and key events; postmortems to help discover root causes and track remediation activities, a user interface that aligns with the rest of the Atlassian portfolio that fosters bi-directional workflow, the ability to automatically trigger events, integration with Slack collaboration software, the ability to encrypt data and Statuspage services integration to make it possible to share alerts with third-party services. Atlassian has also rebranded its Automation Actions to Opsgenie Actions; the company acquired Opsgenie last fall.

    Berkay Mollamustafaoglu, co-founder and head of product for Opsgenie, said now that Opsgenie is part of the larger Atlassian product family there’s clearly more focus on helping organizations integrate best DevOps practices with more structured processes based on the ITIL format. The latest version of the ITIL format provides makes those processes more flexible, but there’s still plenty of room for Atlassian to improve the tenor of the conversation across what has become a bi-modal IT operations environment. As the level of synchronization across those processes increases, the amount of fatigue IT operations teams experience lessens as the number of alerts that need to be correlated across multiple platforms decreases, Mollamustafaoglu noted. In fact, rather than convening in a physical “war room” to resolve a issue, most incidents will increasingly be resolved via online chats, he said.

    It may take a while before a period of détente emerges between advocates of DevOps and ITIL processes inevitably emerges. In the meantime, the more IT services management (ITSM) platforms become integrated with one another, the easier it becomes to achieve that goal. In fact, the major obstacle that needs to be overcome are much more likely to cultural rather than the level of integration that can be achieved using any specific ITSM platform.

    — Mike Vizard

  • Using Jira Software Search to Accelerate DevOps Workflows

    Using Jira Software Search to Accelerate DevOps Workflows

    Imagine driving down the highway and seeming to get a traffic jam at a distance. You realize your car is equipped with GPS to have clear visibility into what’s next and can show exact directions for alternative routes and estimated travel time. It is very easy to pick the fastest and most favorable route to reach your destination by looking ahead proactively and having the set of right tools for collecting information.

    The combination of Dev and Ops teams that are working together to build a faster and more reliable released pipeline is defined as DevOps. Similar to GPS, Jira Software acts as a singular source of truth for information development across your DevOps workflow.

    Complete traceability and visibility of work across different teams can get you surface information and data from an integrated toolchain to the right people anytime. No matter if you’re a team lead, release manager or a tester, the workflow visibility can ensure everyone by letting them know what’s in development and what’s being supported.

    In the latest release of Jira Software version 7.9, there is support added for the dev cycle to show development data from Bamboo, Bitbucket and GitHub in Jira Software search from your DevOps practice. It makes it a lot easier to identify development issues by making informed decisions and faster shipping with software development services.

    Get Answers to Development Questions via Basic Searches

    A new column called Development is added to the default view of Jira’s Issue Navigator in the latest release of Jira Software Server (v7.9). It allows viewing specified information pulled out from Bitbucket Server without clicking into the individual issue. Instead of limiting yourself to the single-issue information, you can see a high-level snapshot of issues coupled together by filtration, to help surface larger trends or problems.

    If this gets stopped at their source, does it really need to move the needle for improving your dev process within DevOps? For instance, if you wish to know how many issues under development, are they in the review?

    If you ever find that one or two developers are getting loaded down with the bulk of pull requests, you can immediately access if redistribution of work is required or not.

    Filter Out Your Development Information Using JQL

    What happens if you need to answer too many complex or open-ended questions? This can become monotonous after a time. You can use Jira Query Language (JQL) to create search queries that are based on development information to uncover key information for avoiding all pending problems.

    The latest version of Jira Software Server comes updated with the syntax to align the JQL query formatting. The users of Jira Software power use JQL for a long time to look at a subset of issues for driving reports and focus on Scrum and Kanban boards. With the help of cross-reference data from developer tools, Jira Query Language seems to be more powerful now.

    Examples of Jira Query Language in Action

    The teams who practice DevOps need critical internal and customer feedback, which helps them to inform features by making them higher quality and more valuable to the end user. Hence, focusing on feedback often creates tension when you decide if the first version is ready to deploy.

    You may ask: What number of issues are done but have not been deployed?

    From this question, you can determine whether the feature is ready to be released and starts collecting feedback or is blocking any issues that need to get resolved prior to release.

    Often, the team’s test builds locally before jumping off to deployment. If the same is the case for your team, then it is a good practice to regularly check the status of the builds.

    You may ask: What number of issues are failing builds?

    If you figure out a lot of failing builds, it may be a signal that the developer environments do not match the deployment. Generally, this is a problem you want to catch and fix right away, so conversely, the set of issues can be the areas where the testers can check acceptance criteria and begin exploratory testing.

    Boost Up Your Search

    You need to surface the information when and where it is needed as most of the teams get the most out of DevOps by bringing development, QA, high-quality releases, more-informed decisions and happy customers. Keep learning!

    — Kibo Hutchinson