Tag: CI/CD

  • CircleCI Looks to Advance DevOps Best Practices Adoption

    CircleCI Looks to Advance DevOps Best Practices Adoption

    CircleCI today launched a developer hub as part of an effort to further advance adoption of DevOps best practices.

    Company CEO Jim Rose said CircleCI developer hub provides access to a set of resources for optimizing continuous integration/continuous delivery (CI/CD) pipelines. In many cases prior to the onslaught of the COVID-19 pandemic, organizations had only partially implemented best DevOps practices, noted Rose. The CircleCI developer hub will make it easier for those DevOps teams to extend the scope of those processes while serving to educate IT teams that have had limited exposure to DevOps workflows, he said.

    The CircleCI developer hub provides access to, among other things, CI/CD configuration optimizations and pre-built packages, migration guides and documentation. There are also reusable snippets of CircleCI configuration code, customized open source Docker images that can be used on any platform, and command-line interfaces (CLIs) and application programming interfaces (APIs).

    Later phases of the developer hub will include an orb development kit to help users quickly create new orbs using CircleCI CLI commands. An orb is a software development kit (SDK) that simplifies integrating the CircleCI CI/CD platform with third-party tools and platforms. CircleCI also plans to provide a much more streamlined search engine experience for CircleCI documentation.

    The CircleCI developer hub was built in part using $100 million in additional funding the company raised earlier this year. Overall, CircleCI claims it processes nearly 2 million jobs across 100,000 projects per day.

    In general, Rose said DevOps is becoming more challenging as organizations attempt to orchestrate the building and deployment of monolithic and microservices-based applications constructed using container and serverless computing frameworks. There are plenty of instances in which deploying a monolithic application is still more appropriate, so IT organizations need to be able to create DevOps workflows capable of spanning multiple classes of frameworks and platforms, he noted.

    Making matters more complex is the testing of microservices now needs to be integrated within production environments, added Rose. It’s not really possible to completely test a microservices until IT organizations see what impact it might have on other microservices that have already been deployed in a production environment, said Rose.

    It’s not clear what impact COVID-19 has had on the productivity of DevOps teams. It might be easier for developers to generate more code working from home than in the office. However, generating quality code at the right time during a project requires a lot more orchestration when members of the application development team are highly distributed. More than a few organizations either already have or soon will be tuning DevOps workflows to align with the so-called new normal.

    Of course, there are plenty of places to find tips and advice when it comes to building and extending DevOps workflows. The challenge is creating workflows that are not only flexible and resilient but also simple to implement and maintain.

  • How Serverless Technologies Can Achieve Optimal DevOps Practices

    How Serverless Technologies Can Achieve Optimal DevOps Practices

    Growing competition and increased customer expectations drive the speed of development. Adopting DevOps, meanwhile, can be a challenge, as it includes adjusting practices and new infrastructure. However, although engineering resources may be slim, serverless offers new solutions to tackle the DevOps challenge. From improved IoT devices to cost-effective machine learning applications, the serverless ecosystem is helping promote DevOps adoption.

    Why Is Serverless Beneficial for DevOps?

    DevOps accelerates development while stabilizing downtime, giving enterprises a competitive edge, a quicker product maturity in terms of features and capabilities and an improved customer experience. Although the benefits are appealing, DevOps adoption is expensive and time-consuming. Serverless can combat the barriers and support the implementation of DevOps solutions, at lower cost and with greater returns.

    Serverless technologies provide a pay-as-you-go model, allowing enterprises to pay for the resources used. For instance, with AWS Lambda, users pay based on the number and duration of invocations, potentially lowering costs. Functions as a service (FaaS) could become more expensive than containers, depending on the traffic experience. The higher and more consistent the traffic, the higher the costs of serverless tools, and these costs can rise higher than container costs.

    Since serverless technology is auto-scalable and fully managed, it allows teams to focus on the business logic that the DevOps infrastructure was actually built for, instead of spending countless hours maintaining the DevOps architecture.

    Availability and Performance Monitoring

    FaaS services such as AWS Lambda or Azure Functions are comparatively easy to spin up, auto-scalable and cost-effective. The functions can make API calls to your service, and API calls can be made by the user via the front-end interface. These periodic checks ensure your services are available continuously and any failures incurred in the production environment can be captured by monitoring tools to inform you of any performance degradations. The alerts from the monitoring tools can be consolidated by incident management SaaS tools.

    FaaS functions can be used for automatic availability and performance checks. However, serverless event buses communicate alerts as invocations of the FaaS functions throughout the DevOps infrastructure, lowering the overall cost from the pay-as-you-go model and auto scalability of FaaS functions.

    ChatOps Improve the DevOps Process

    Developed at GitHub, ChatOps is a conversation-driven development that allows users to type commands in a chat tool to kick off the CI/CD process through custom scripts and plugins. The operation of the scripts requires backend support, which is where serverless technologies can support.

    FaaS functions give DevOps engineers the ability to simply write the script to perform the intended operations and upload it to the function while ensuring that the chat tool can invoke it. This removes arduous container orchestration and networking setup. Furthermore, costs are only incurred when the FaaS function is invoked via the chatbot, not on an hourly basis.

    Serverless Enhances the CI/CD Process for Continuous Deployment

    Similar to ChatOps, serverless can be used to enhance the CI/CD process, but unlike ChatOps serverless can automate the entire process by merging pull requests to deploy in production. This is also known as GitOps.

    Conceived by Weaveworks, GitOps is a methodology for Kubernetes cluster management and application delivery. By leveraging Kubernetes’ convergence properties, continuous delivery is triggered by git push. GitOps allows Kubernetes cluster management and application delivery by using Git as a single source of truth for declarative infrastructure and applications. With Git at the center of delivery pipelines, developers can accelerate pull requests and simplify application deployments and operations tasks to Kubernetes.

    GitOps provides a “source of truth” for the infrastructure and application code to further increase the velocity of development teams. The workflow that makes this possible starts with CI tools to push docker images to hosting tools. Then cloud functions copy the configs and helm charts from the master storage bucket to master git repo. Finally, GitOps operators update the cluster according to the config charts and pull helm charts by the Lambda function.

    By copying the helm charts, FaaS functions can be used to the master git repo. The FaaS functions are easy to set up and cost-effective, which means DevOps engineers can focus on other parts of the GitOps infrastructure and achieve low costs in the process.

    The Road to DevOps is Challenging, But Serverless Can Help

    Serverless can relieve the complexity of DevOps adoption through its pay-as-you-go, auto-scalability and fully managed services, enabling a more efficient and cost-effective implementation of DevOps infrastructures. Serverless technologies can be used across the DevOps stack from development and testing to CI/CD and incident management, it operates at optimal cost and is highly effective in development velocity and code reliability.

  • CircleCI Adds to Salesforce CI/CD Orbs Collection

    CircleCI Adds to Salesforce CI/CD Orbs Collection

    CircleCI today announced it has extended its CI/CD support for DevOps teams building applications that extend the software-as-a-service (SaaS) platform from Salesforce.

    Company CEO Jim Rose said interest in building applications that complement the Salesforce platform is rising sharply in the wake of the economic downturn brought on by the COVID-19 pandemic. Rather than build entire applications from scratch, IT teams are advancing digital business transformation initiatives by leveraging the core suite of applications Salesforce makes available as a cloud service, he noted.

    Many of those applications are built by professional developers that have embraced best DevOps practices, Rose said.

    To reduce friction for those DevOps teams, CircleCI is now adding support for a Salesforce Apex orb. An orb is a set of pre-configured connectors that CircleCI makes available for its continuous integration/continuous delivery (CI/CD) platform. The company has created more than 1,600 CircleCI orbs. Salesforce Apex is a proprietary object-oriented language that Salesforce makes available to developers.

    The Salesforce Apex orb automatically deploys changes to a production application, runs unit tests that are displayed using the Salesforce Platform user interface and tracks version control on commit.

    CircleCI has also updated its existing Salesforce command-line interface (CLI) orb to tighten integration.

    Rose said that as the pace of application development continues to accelerate, more IT teams are applying best DevOps practices to how they build and deploy applications as part of an effort to make the whole organization more resilient to change. Others are simply looking to modernize existing DevOps workflows that currently run on legacy CI/CD platforms.

    In either case, Rose said most end customers would prefer providers of CI/CD platforms to focus on making DevOps teams more efficient rather than moving into adjacent market segments to increase the size of their total addressable market. Those latter strategies are, in many cases, trying to drive consolidation of the overall DevOps market to woo potential investors rather than focusing on customer interests, he noted.

    It’s too early to say how the DevOps platform wars will play out. The size of the overall market continues to expand as the rate at which mergers and acquisitions are occurring accelerates. Regardless of the outcome, more IT organizations are under pressure to deliver more robust software faster, said Rose, noting the Salesforce application developer community represents only one segment of that expansion.

    Each organization will, of course, need to chart its own DevOps course. It’s not uncommon for different teams with the same organization to have standardized on multiple DevOps platforms. There may come a day when the need to reduce costs may force those organizations to rationalize DevOps platforms. However, as long as the rate at which high-quality software is delivered continues to improve, just as many organizations may conclude it’s just as well to leave something alone that doesn’t appear to be broken.

  • Top Pressing Concerns for CI/CD in 2020

    Top Pressing Concerns for CI/CD in 2020

    The tech landscape is changing rapidly. With the need for increased development velocity, CI/CD has become ubiquitous among most organizations. Yet, with the growing number of microservices, CI/CD may be tough to wrangle without the right strategy.

    At the same time, it’s difficult to keep pace with the constant evolution around CI/CD. So, what is the state of the CI/CD space in 2020, especially in these turbulent times? What do stakeholders see as top pressing concerns companies should consider to advance their release fluidity?

    For this article, I interviewed two stakeholders on the latest trends and industry cooperation around CI/CD. Read on to discover what two CI/CD thinkers, Tracy Miranda, board chair, Continuous Delivery Foundation (CDF), and Lachlan Donald, CEO, Buildkite, see are pressing concerns for CI/CD in 2020.

    More Microservices, More Problems

    With the number of microservices rising to the hundreds (or thousands) for some enterprises, maintaining consistent release strategies across the board could easily become a nightmare. If the goal is to replicate a unique CI/CD pipeline per microservice, pipeline automation and configuration management become top concerns.

    “Automation will be key,” said Miranda. “We can no longer afford to be writing each CI/CD pipeline by hand; we will need new approaches.” She added that recent industry discussion shows “configuration management is a top concern for CI/CD practitioners.”

    Tools like Jenkin X could enable this sort of automation, she noted. Companies should consider evolving their CI/CD pipelines with better configuration management.

    Platforms Must Evolve

    The recent “State of the Cloud Report” from Flexera found 39% of IT leaders saw implementing CI/CD in the cloud as a top priority. According to Miranda, the global crisis seems only to accelerate the need for cloud and CI/CD automation.

    But, traditional CI/CD platforms aren’t always suited for modern development workflows with numerous pipelines. For Donald, an evolution in new tooling is absolutely necessary to help companies keep pace.

    “We’re at a point where organizations need to completely rethink their approach to CI/CD,” Donald said. “Traditional CI/CD platforms are not suited for modern development workflows.” He cites slow speed, unreliability, scalability limitations and security risks as common hangups among many CI/CD tools.

    Lack of Clarity in CI/CD Market

    The market has expanded significantly to address the gap in CI/CD tooling effectiveness. According to Miranda, this has led to a continuous deployment tooling ecosystem wrought with interoperability and competing styles.

    “My biggest concern is the proliferation of tools and platforms with a lack of interoperability and lack of clarity of how to best use them or whether they are fit for purpose,” Miranda said.

    These differences make it difficult for developers to find the right integrations that work for their environments, leading to wasted time and effort. “Developers will experience growing pains with their CI/CD platforms as they work to keep up with the constant demand for quality software,” acknowledged Donald.

    Lack of Standards

    Part of the lack of clarity resides in the fact that there are little to no standards emerging in the CI/CD space. Aside from Accelerate rising as the “bible” for software delivery, Miranda sees a lack of standards in the CI/CD space.

    “Not having standards or de facto standards is a problem,” she said. “For example, why is there no de facto standard for reporting pipeline test results?”

    Advancing Open Source CI/CD Tools

    To improve Interoperability throughout the CI/CD industry, bodies such as CDF are working on setting general guidelines. Miranda described how CDF is accomplishing this, by supporting a CDF Interoperability working group, sharing CI/CD practices and maintaining open source CI/CD projects. Two CDF projects she finds quite compelling are Tekton, a pipeline execution engine, and Jenkins X, a new CI/CD platform for pipeline automation.

    Cloud vs. On-Premises: A False Dichotomy?

    In analyzing the CI/CD tooling ecosystem, Donald recognizes a recurring dichotomy; that companies must choose between the security of on-premises and the speed of cloud-native. In reality, this dichotomy may be false.

    “It is possible to have the best of both worlds,” he said. “A hybrid strategy [is] the solution for testing and deploying software at scale without compromising security or performance.’

    As opposed to cloud tooling, self-hosted CI/CD control planes could grant developers more code control and help meet security standards. “I believe self-hosted agents are always a good idea,” Donald said.

    As we recently covered, a hybrid cloud approach is picking up steam. Similarly, Jenkins X is designed to run on any Kubernetes cluster, regardless of on-premises or cloud, demonstrating industry movement toward tooling neutrality and hybrid motivations.

    Moving Beyond PASS or FAIL

    There is a reductive tendency in CI/CD to simply check whether a build passed or not. But, this mindset misses an enormous amount of useful information and undervalues the test and release suites themselves.

    “Teams should get granular about what worked and what didn’t,” Donald said. DevOps teams must evolve beyond a “PASS or FAIL” mindset to analyze more minute aspects of the build process itself.

    For Donald, this also means shifting to treat test code performance “as a first-class citizen, applying modern development and scaling practices to it and allocating the necessary resources to it.”

    Future Evolution: Progressive Delivery and Hybrid Approach

    In closing, I asked Miranda and Donald their thoughts on the future CI/CD evolution. They shared their perspectives on where CI/CD needs to evolve.

    Miranda views progressive delivery as the next milestone. With progressive delivery, teams deploy services in a staged manner, she said. “Tools, technologies and processes that fall under the ‘progressive delivery’ umbrella will be the next milestones for improving deployment speed and efficiency.”  Building blocks such as services meshes could help advance this process, she noted.

    Donald stressed the need for a hybrid approach to CI/CD. A neutral control plane could grant better control and future-proof continual release strategies.

    Assessing the CI/CD Landscape

    In summary, our panel shared thoughts on the top concerns for CI/CD in 2020:

    • Platforms must evolve: Teams should rethink their approach and emphasize automation in pipelines.
    • Lack of clarity: There are few standards and a lack of clarity among tools. This confuses developer adoption.
    • Interoperability: A focus on interoperability is critical toward advancing the industry.
    • Unhelpful dichotomies: The cloud-native versus on-premises divide may not be helpful for a hybrid strategy; thus, it’s recommended to seek out platform-neutral tools.
    • Move beyond PASS or FAIL: Switch the mindset to “Test code = application code.”

    High performant organizations must scale their technology tremendously. With this desire comes a mounting strain on how companies adopt a continuous deployment strategy. Without a proper CI/CD plan, business agility is sacrificed.

    As an ending note, I absolutely love Donald’s statement: “A good litmus test for how well a company is run is their approach to CI/CD.” Perhaps what all can agree on is that companies must prioritize CI/CD, as it is now business-critical. Otherwise, deployments may be numbered for those organizations that don’t adapt.

  • GitLab Extends Scope, Reach of CI/CD Platform

    GitLab Extends Scope, Reach of CI/CD Platform

    The latest update to the GitLab continuous integration/continuous delivery (CI/CD) platform adds a bevy of additional capabilities spanning multiple capabilities, from being able to manage application development and deployment projects in smaller chunks to allowing remote teams to work more efficiently.

    Brendan O’Leary, senior developer evangelist for GitLab, said a Minimal Viable Change (MVC) capability in version 13.2 enables DevOps teams to break down work into smaller, more manageable chunks that are less disruptive. At the same time, GitLab is further reducing disruption by enabling deeper integration with Jira project management software from Atlassian. DevOps teams can provide bulk updates to projects using Jira in addition to creating confidential “epics” that only a limited number of users can access, said O’Leary.

    GitLab Geo has also been updated to improve replication performance to ensure local content is fresh. That capability has become especially crucial for DevOps teams that now routinely have large numbers of members who are working from home to help combat the spread of COVID-19. Many DevOps teams were already often working remotely prior to the pandemic; now large organizations are moving to extend those efforts at scale because it’s not clear when, if ever, DevOps teams might be heading back into an office, noted O’Leary.

    Other new capabilities include CI test results within a Release Evidence module for tacking compliance data; a global search tool for GitLab.com; tools for tracking designs stored in GitLab; and the ability to run custom load tests as part of a CI/CD pipeline more easily.

    DevOps teams can now associate Feature Flags with related issues; invoke container host monitoring and blocking; track changes to wiki pages; drive feedback into web-based integrated development environments (IDEs) in real-time; enable PHP developers to access a Composer Repository to discover dependencies; and employ a Code Quality Merge Request widget.

    Finally, DevOps teams can run the GitLab Runner tool to launch jobs on instances of z/OS running on IBM mainframes. O’Leary said that capability is especially critical as more organizations that have mainframes embrace best DevOps practices to drive digital transformation initiatives.

    In general, digital business transformation initiatives are fueling adoption for DevOps as organizations look to accelerate these initiatives to reduce overall costs and potentially increase revenue. As part of those efforts, O’Leary said organizations are looking for a highly integrated DevOps platform that minimizes the amount of time and effort DevOps teams need to spend integrating components and managing the platform. That urgency is also driving more organizations to embrace the software-as-a-service (SaaS) edition of GitLab, he added.

    In the meantime, competition among CI/CD platform providers continues to intensify in the wake of an ongoing wave of consolidation. The paradox is that consolidation is not being driven by declining demand; rather, many IT organizations are looking to streamline DevOps processes by standardizing on a single platform. As such, the race to add as many capabilities to a CI/CD platform as possible has never been more heated.

  • OverOps Partners With GitLab to Analyze Code Earlier

    OverOps Partners With GitLab to Analyze Code Earlier

    OverOps has allied with GitLab to integrate a tool that analyzes code at runtime to identify issues with a continuous integration/continuous delivery (CI/CD) platform.

    Eric Mizell, vice president of solution engineering for OverOps, said the plugin for the GitLab CI/CD will make it easier to surface issues with code earlier in the DevOps pipeline. OverOps’ quality gates help determine if code is safe to promote and automatically blocks unstable releases from moving forward to production.

    OverOps combines static and dynamic analysis of code as it executes by relying on machine learning algorithms to collect data. That analysis can be accessed either via dashboards based on open source project Grafana software or shared with other tools via an open application programming interface (API). It analyzes code at runtime to identify all new, increasing, resurfaced and critical errors in a release. OverOps then generates a code quality report that ranks issues in terms of potential to impact end users and application functionality.

    According to a recent survey of more than 600 software development and delivery professionals conducted by OverOps, more than 50% of respondents spend a day or more per week troubleshooting code-related issues.

    The survey also finds that nearly 25% of organizations experience critical/customer-impacting production issues on a daily or weekly basis.

    The earlier code issues are detected the less expensive they are to fix. OverOps is making the case for making its tool part of the quality assurance gate within any CI/CD pipeline.

    The paradox many organizations find themselves in is that as DevOps processes enable them to build and deploy applications they wind up spending a lot more time debugging those applications.

    Eventually, developers wind up spending more time fixing existing application code than developing new applications. Tools such as OverOps are employing machine learning algorithms to reduce the amount of time spent discovering code issues, which should free up more time to write new code.

    OverOps captures machine data about every error and exception at the moment it occurs, including details such as the value of all variables across the execution stack, the frequency and failure rate of each error, the classification of new and reintroduced errors and the associated release numbers for each event.

    DevOps teams historically rely on log data to manually search for anomalies indicative of issues with code. Not only is OverOps faster, but the algorithms will also surface uncaught and swallowed exceptions that would otherwise be unavailable in log files.

    There are a lot of aspects of DevOps that now can be better handled by machines than humans. That doesn’t mean humans will be replaced anytime soon. However, the bulk of time-consuming and monotonous DevOps tasks that exist today are eventually going to be performed by a machine faster and with greater precision. The challenge and opportunity now are identifying the tasks where machine learning algorithms can have the most impact sooner than later.

  • Financial Services: Future Proofing Your Digital Transformation Strategy

    Financial Services: Future Proofing Your Digital Transformation Strategy

    The Financial Services: Future Proofing Your Digital Transformation Strategy virtual event will explore the state of development and DevOps in the finance industry, and how organizations can digitally transform their strategy in order to release new, compliant applications and safely adapt to change at any speed demanded by the business. The virtual event will take place on July 9 at 2:30 p.m. CEST (8:30 a.m. ET).

    CloudBees is bringing together a stellar line-up of thought leaders to discuss the impact of digital transformation in financial services, including:

    • Sacha Labourey, CEO of CloudBees
    • Jost Hoppermann, VP and principal analyst at Forrester
    • Chafin Bryant, software engineering manager at Capital One
    • Keith Blizard, SVP of public cloud services at Fidelity Investments

    The experts will discuss the challenges the financial services industry faces in adopting DevOps.

    At the Financial Services: Future Proofing Your Digital Transformation Strategy virtual event you will learn:

    • How to assure separation of duties and access controls without stifling innovation.
    • About Capital One’s DevOps success story and how they’ve tackled some of the unique challenges of CI/CD in the finance industry.
    • How to incorporate legacy and hybrid technology into your release trains and processes.
    • How to scale across geographies, teams, applications, regulations and environments – and still get the velocity and reliability expected by the business.
    • About Fidelity’s cloud transformation journey and CI/CD best practices.
    • How to build bridges across devs and ops; employees and contractors.

    Join the CloudBees community and learn how to future-proof your digital transformation strategy. To check out the agenda and to register, visit the Financial Services: Future Proofing Your Digital Transformation Strategy website.

  • How to Use Microservices To Evolve DevOps Pipelines

    How to Use Microservices To Evolve DevOps Pipelines

    Enterprises are quickly becoming an intricate mesh of many applications. As companies create more and more microservices, their deployment environments are becoming increasingly elaborate. Without proper configurations, a microservices road map could quickly become unmaintainable.

    According to DeployHub CEO Tracy Ragan, if development teams are pushing points to a cluster continuously, application development can suffer without high visibility into their dependencies and application interrelationships.

    In her recent talk, “Evolving Your Pipeline for Microservices with DeployHub,” presented by the Continuous Delivery Foundation (CDF), Ragan, also Governing Board member of CDF, discussed ways in which teams can obtain improved insight into microservices delivery pipelines.

    Microservices Tracking Issues

    A 2018 study conducted by O’Reilly found that 86% of respondents reached mild success in adopting microservices in production. Only 15% reported “massive success.” These results demonstrate both the excitement surrounding microservices and the rarity of flawless execution.

    “I’m a huge fan of microservices,” said Ragan. “This is an exciting time to be in software development.” Microservices break from the traditional software delivery model, she said, forcing teams to emphasize the runtime. However, with this shift, it becomes easy to lose the logical views between applications.

    According to Tracy, dependency tracking and version control are top issues in maintaining microservices arrangements. With continuous updates, it can be challenging to keep track of which version a service is using. “Microservices development falls apart without a coherent management approach,” she said.

    Losing Visibility Moving From CI to CD

    Part of the loss of visibility stems from the move from CI to CD. Continuous integration (CI) involves routinely updating source code and starting the compile process. This is often done every hour, as opposed to every week or month. With traditional CI, the system created a package and scanned for dependencies at compile. This was the first step in the continuous journey.

    However, nowadays, microservices are typically linked at runtime or in the Kubernetes deploy file as part of a continuous delivery (CD) processes. In doing so, we’ve lost a certain amount of visibility that CI granted. Ragan likened it to “hammering a wine glass”—we still have the constituent parts, but they lie shattered in pieces.

    Large microservices suites of 50, 100 or even 300 are not uncommon these days. Such large ecosystems require logical tracking of versions and dependencies. Ragan argued that development teams need a workaround layer to replace the critical configuration management lost in CI compile reports. Visibility into interrelationships is necessary to trace how changes in one service will impact other applications.

    Enter Ortelius

    Ortelius is a package that helps with continuous microservices management. Ortelius, named after Abraham Ortelius, the inventor of the first atlas, helps trace the connections between services to improve an ecosystem’s visibility.

    To get an idea of how it behaves, consider an e-commerce store. To reach an evolvable microservices pipeline, each microservice should be independently deployable with its own workflow. For example, an e-commerce store may require a product microservice, payment microservice and an authentication microservice. These reusable components are independently deployable but rely upon one another to function as a whole.

    At a macro scale, an enterprise with thousands of inter-application dependencies would visually resemble a constellation of nodes. An extreme example of this may resemble the Netflix Death Star, a mass conglomeration of intersecting points. Ortelius grants transparency into an otherwise tangled mess as an “internal marketplace for microservices,” said Ragan.

    Paring Ortelius With DeployHub

    Ortelius is the open source core of DeployHub, an open source SaaS for sharing and releasing microservices. Ortelius, paired with DeployHub, enables teams to see the logical application map, exposing the complexity of microservices dependencies.

    Developers add DeployHub to any existing microservice development workflow prior to release. Ortelius is then called to increment the service and record dependency information. DepoyHub then uses for Helm or Ansible for the actual code push, and adds the record metadata and adds the tracking and mapping layer. Having such information is still critical for reporting like dif reports or a bill of materials report, noted Ragan.

    This sort of solution, Ragan proposed, is also vital for continuous configuration management—when a microservice changes, the team will always be aware of the new application version.

    The New Microservice Pipeline Model

    As noted above, in the traditional model, DevOps teams map dependencies in the CI stage. When an API developer publishes to the main catalog, they define specific attributes based on the microservices. A versioning engine will then typically map to visualize dependencies.

    Ragan outlined steps for a new microservices pipeline:

    1. Build image: Compile and build the container image.
    2. Put into registry: Quay or Docker registry. Specific for container registries.
    3. Track service-application configurations: This is where we collect configuration data to map the structural relationships.
    4. Push to cluster: DeployHub helps to standardize this process across an organization.
    5. Collect feedback: Configuration reporting and impact analysis.

    Core to this process is being able to independently deploy microservices and aggregate useful information. Of course, this is an incomplete model—a complete pipeline would utilize other steps including testing and automated security scanning as well.

    Benefits

    By streamlining the microservices journey in this way, repos will be broken out and teams no longer go through one big long workflow. According to Ragan, the visibility garnered from this method could help organizations in multiple other ways:

    • Reduce time: Ragan estimated automated application relationship mapping could replace one to two hours of manual work per week per development team.
    • Reusability: Decomposing applications into their domains aids reusability across an organization.
    • Avoid redundancy: Code sharing can significantly reduce duplicated code, thus avoiding redundancy and increasing flexibility.
    • Visibility: Detailed application to service relational knowledge could empower SREs to make better data-driven decisions.
    • Centralize: Helps standardize container deployment processes regardless of cluster type or collection, aiding both traditional and containerized microservices deployments.
    • Versioning: Improved insight into versioning helps when you need to share services externally.

    Lastly, what’s nice is Ortelius is open source on GitHub. Ortelius adopts an open community format to accept feedback. “Democratization is the core reason we have open source,” said Ragan. Ortelius can be used for free, or with added features from DeployHub pricing for enterprise cases.

    A Confluence of Software Delivery Styles

    Managing continuous software delivery across many microservices leads to unprecedented issues. In solving these issues, the industry appears to be fracturing slightly. For example, the model promoted by Ragan is in contrast with a recent presentation I covered from Codefresh.

    Where Ragan suggested improving visibility into independent microservices deployment pipelines, Dan Garfield of CodeFresh suggested adopting a single CI/CD pipeline to operate all microservices from a single control plane. As it goes so often in software tooling, the use case will likely dictate adoption.

    Whatever the software delivery process, when decomposing applications—or “taking the hammer to the wine glass,” as Ragan called it—we probably shouldn’t sacrifice visibility into the metadata associated with application versions and service to application interrelationships. If such data is lost or not managed correctly, we could lose a lot of potential value.

    For more information on evolving DevOps pipelines, watch the CDF-presented webinar here. DeployHub also published an adjacent article on this subject here. You can also contribute to Ortelius on GitHub.

  • JFrog Extends Reach and Scope of CI/CD Platform

    JFrog Extends Reach and Scope of CI/CD Platform

    At its online JFrog swampUP Conference today, JFrog announced it has extended the reach of its ability to distribute software to include options based on peer-to-peer and content delivery network (CDN) mechanisms.

    In addition, JFrog expanded the reach of the JFrog Pipelines continuous integration/continuous delivery (CI/CD) platform, enabling DevOps teams to build their own library of reusable pipeline steps via an Extensions Development Kit (EDK). DevOps teams can encapsulate frequent and common actions in their pipelines that can run sequentially or in parallel. That approach also serves to reduce the need to rely on plugin modules to extend a JFrog delivery pipeline.

    Finally, JFrog has added another free public artifact center that provides a means to manage Helm charts, which are widely employed to deploy applications on Kubernetes clusters. ChartCenter is intended to make it easier to deploy microservices based on containers.

    JFrog CEO Shlomi Ben Haim said all three additions to the JFrog portfolio extends the ability for users to manage the entire DevOps workflow from integration to delivery regardless of what type of software is being deployed or where it is installed.

    As DevOps teams look to deploy software on edge computing platforms within an internet of things (IoT) environment, Ben Haim said they will need to be able to employ either a peer-to-peer or CDN-based approach to manage that process efficiently. Existing mechanisms are not designed to handle large volumes of artifacts that need to be delivered in a specific order. The new mechanism added to the JFrog CI/CD platform enables DevOps teams to achieve that goal without having to acquire a separate platform, he said.

    In fact, Ben Haim noted, efficiently delivering software to edge computing platforms represents the next great leap forward for DevOps. Achieving that goal, however, will only be practical if the entire CI/CD workflow process keeps track of all the dependencies and metadata end-to-end, he said, noting that approach will enable endpoints to pull only the delta code required to update the software after an application is initially deployed.

    There is no doubt extending best DevOps practices to edge computing platforms will be a major challenge. Most DevOps teams already struggle with CD because each platform software is being deployed on is unique. Because of a general lack of standardization in terms of potential endpoints that might be deployed at the edge, that “snowflake” issue is likely to become even more exacerbated as IT environments become more distributed than ever.

    In general, Ben Haim said far too much of the DevOps focus continues to be on source code management when in reality the biggest issue IT organizations face is how to efficiently manage binaries. At a time when organizations are making massive investments in digital business transformation, Ben Haim noted the rate at which software is deployed and updated is about to accelerate dramatically.

    As such, Ben Haim said it’s now only a matter of time before DevOps workflow processes will need to be able to scale well beyond their current limits.