Tag: case study

  • Case Study: Laserfiche Builds Hybrid Cloud for ECM

    Case Study: Laserfiche Builds Hybrid Cloud for ECM

    Laserfiche is a privately owned software development company that creates enterprise content management (ECM), business process automation, workflow, records management, document imaging and webform software. The company provides secure document management, image capture, electronic forms, workflow automation, digital signatures and DoD 5015.2-certified records management, “Automating and streamlining business processes with prepackaged solutions for contract management, HR onboarding and new account openings,” says Thomas Phelps, vice president of Corporate Strategy & CIO.

    Laserfiche also maintains a business process library including templates that enable its customers to hit the ground running on new ECM deployments.

    The business counts Fortune 500 companies among its customers, serving industries including government, education, health care and finance. “We’re an enterprise content management software leader in state and local government, with a majority of the Center for Digital Government’s top digital cities and counties as our customers,” Phelps says.

    This is the story of the company’s addition of a cloud infrastructure and its plans for a hybrid cloud.

    Embracing DevOps and its Culture in Preparing for the Cloud

    Laserfiche embraced DevOps and its methodologies and tools simultaneously as it began development on its cloud infrastructure, the Laserfiche Cloud, which the company announced in January 2014 at the company’s worldwide Empower user conference.

    With that, Laserfiche took a sharp detour from its usual scrum development practices, adopting DevOps for its ability to encompass the development needs and demands of a cloud project.

    To use DevOps to move up the timetable on bringing the Laserfiche Cloud to life, the company had to swallow the DevOps culture, tools and processes whole. “We created a separate, dedicated cloud infrastructure team responsible for rapid deployments of test and production environments. We assigned a member of each software product team as a designated Laserfiche Cloud liaison to represent each product team including Laserfiche Forms, Laserfiche Mobile and Laserfiche Connector teams with respect to any feature updates, testing or releases for Laserfiche Cloud,” Phelps says.

    Though the Laserfiche Cloud infrastructure development team works in unison, each team member has the opportunity and responsibility to isolate, program and interweave software and services. Proper governance and controls ensure this means progress rather than setbacks for the ongoing cloud project.

    Development adopted PowerShell scripts, open-source and homegrown tools and Chef to promote advancement of a DevOps pipeline for its cloud infrastructure.

    Software Development Before DevOps and the Cloud

    Before moving to DevOps, the company developers relied on scrum-based agile development methods. The process followed from planning two-week sprints, through developer programming on desktop machines, unit testing, committing daily code changes, testing using daily automated builds and ultimately ending with retrospectives. Software products were tested individually by their own teams on separate VM clusters assigned to each team.

    That process allowed for one big release per year with smaller releases before and after. “Before DevOps, we manually uploaded release packages to our support site for customers and resellers to download, install and configure the Laserfiche ECM,” Phelps notes.

    After DevOps, with the Cloud

    The Laserfiche Cloud, a software-as-a-service (SaaS)-based ECM subscription service, offers mobile synchronization, e-forms and workflow automation in addition to its previous services, once offered only on premises. “The Laserfiche Cloud provides robust granular system security, encryption and audit reporting to bring centralized control and transparency to business operations,” Phelps says.

    With the cloud infrastructure in place, the company now is using the same DevOps culture, structure, tools and people to develop a hybrid cloud version. “We’re developing a hybrid solution, using Laserfiche Web Access, to provide access to hosted content and enable collaboration with third parties, business partners and customers,” Phelps notes.

    Results, Benefits

    “Instead of taking days or weeks for information technology or our software testers to deploy new VMs and infrastructure, the cloud infrastructure team can spin up new test environments within hours,” Phelps says.

    The company progressed from one major product release a year to updates every one to three months by automating the process of configuring new environments and deploying software. “Many software engineering teams have begun adopting a cloud-first development system where they develop and test binary packages and use internal tools to deploy the packages for testing,” he notes.

    Laserfiche can now satisfy customers with larger, swifter feature enhancements to its Laserfiche Cloud. “The cloud infrastructure team works closely with our software engineering teams, using accelerated release management processes, to perform upgrades in hours within an approved maintenance window,” Phelps says.

  • TASC Powers Up DevOps Pipeline

    TASC Powers Up DevOps Pipeline

    Technology team members at TASC, a leading administrator of employee health benefits, were feeling the chains of manual processes that kept them from moving software out at more than a snail’s pace. Development, operations, quality assurance (QA), project managers (PMs) and business analysts who were pushing code to test, staging and production environments or performing user accepted testing (UAT) tests needed to forward features through the pipeline much more quickly.

    “We were doing one release a month, shutting down the entire website for six to eight hours on a Saturday morning to complete deployments,” says John Gildenzoph, DevOps engineer at TASC.

    The company took to orchestrating its pipeline using Automic Release Automation (ARA) to onboard DevOps and catapult software innovations into production.

    Manual Challenges

    Before ARA, TASC used Jenkins—that was pretty much its first step into DevOps-style automation. Before that, the company’s processes were, for the most part, all manual, implemented with a source code repository.

    “For anyone to deploy the application for development on their workstation, or to a test environment or even to production, they had to go out to the server, check out the source code, build the source code and deploy the artifact,” says Gildenzoph.

    TASC was doing that on up to 30 JBoss servers—which were its main web servers—using only two developers. One developer started on the first node and the other started on the last node as they worked toward the middle, updating each server individually and manually, he says. “We came from the Dark Ages where there were really no other products we were using other than the servers and our version control software. Jenkins was the first iteration where we figured out that we needed to be running builds all the time,” Gildenzoph notes.

    Uniting DevOps Tools, Filling Gaps

    TASC uses ARA to unite a variety of DevOps tools into the pipeline and to fill gaps where there isn’t a specific tool. “ARA is platform-agnostic. You can use it like an assembly line and you can plug the worker applications in along the assembly line as you like,” Gildenzoph says. In one example, TASC uses Jenkins as one of those “worker applications,” i.e., as its build tool: ARA tells Jenkins to build the software, then moves the software along itself to the next tool to do the next job.

    According to Gildenzoph, all a company needs to add best-in-class tools at each step in the development process along the pipeline is a command line interface (CLI) or API that enables them to script that tool in to integrate with ARA. That way, if the company decides to use a new tool for any part of the process, it can simply script that tool into the ARA at that point, rather than replace the entire pipeline with one new tool for everything.

    TASC also uses ARA to orchestrate in its use of Amazon EC2 and the ECS products. At the same time, TASC is working to add the management of Docker containers into ARA in the same way.

    TASC IaaS

    TASC uses ARA to create the entire dev, test, staging and production environments where the company will deploy the software. Using the ARA and its automation engine, which is a sort of complex chron that develops the workflows, TASC interacts with its Amazon cloud presence to create the entire application stack.

    “We see that Automic is working on its next evolution of the ARA product, which is a provisioning product that will interact with various cloud technologies such as Amazon or OpenStack so we will be able to create that environment in less of a homegrown manner. It will be more of a drag-and-drop capability with run books to interact with your cloud,” Gildenzoph says.

    These cloud technologies also will be like the applications/worker setups in Gildenzoph’s ARA assembly-line analogy.

    Revving Up Results

    “We moved from our original manual scenario to the point where in some cases we don’t need downtime to deploy the software. We have the orchestration in place and it manages to bleed off part of the cluster, update that cluster, and then bring those portions back online so that our customer doesn’t notice,” says Gildenzoph. This benefits internal and external customers who use the site for call center processes and submitting flex claims, respectively.

    TASC is more agile since the adoption of Automic, releasing software typically on a weekly timetable. This enables the business to respond to requests from customers for new features, innovations and enhancements to the site more quickly and efficiently.

    When TASC purchases another company to add its products to TASC’s, an accelerated pipeline enables the company to onboard that company and products more swiftly and seamlessly.

  • SimplyHealth Uses DevOps to Manage Mobile Testing

    SimplyHealth Uses DevOps to Manage Mobile Testing

    SimplyHealth, a private company health insurance plan provider in the United Kingdom, saw its mobile web traffic trending upward with no end in sight. “While this was good news, there was concern whether the customer experience and the company’s ability to provide continuous application delivery on mobile devices might erode as a result,” said Chris Dale, information technology test and release manager at SimplyHealth,

    A good half-dozen challenges in mobile testing and development stood at the crossroads between mobile customer demand and SimplyHealth’s mobile development speed and ability to respond to needs for improvement.

    With some help from Mobile Labs, a provider of internal cloud mobile device testing for software, SimplyHealth allayed its fears of customer dissatisfaction.

    Mobile Web Test, Dev Challenges

    Dale noted SimplyHealth’s challenges to mobile web test and development were many. Among them:

    • Testing came late in development, causing the testing team to find issues at later in the development process and leading to costly rework for developers.
    • The vast array of mobile handsets that needed to be tested against, which affected productivity and increased expenses because of the time spent searching for, ordering and waiting for devices to be shipped to SimplyHealth for testing.
    • The development team’s use of mobile device simulators for testing mobile software on different device platforms—a process that did not represent accurately the behavior of actual devices.
    • The differing behaviors of Apple and Android devices in some functional areas, which made it impossible to do cross-platform testing with a single script.
    • Testing eventually  became a bottleneck, jeopardizing SimplyHealth’s award-winning customer service levels for its mobile customers.
    • The digital marketing team had difficulties in verifying customer experience on mobile devices.

    An all-encompassing solution for the SimplyHealth mobile web testing team would enable early testing and cross compatibility with the needs of all affected departments, including marketing.

    Dale said the tool would have to meet 34 requirements, including:

    • Allow for the highest levels of security and compliance with the Data Protection Act (similar to HIPAA regulations in the United States)
    • Provide the ability to use the existing automation framework and toolset and hook into SimplyHealth’s continuous integration solution for automatic test execution
    • Offer a way to swap devices in and out quickly and easily
    • Provide easy accessibility from any location
    • Have a simple user interface
    • Maintain high levels of performance
    • Offer scalability for future growth
    • Come with backing by dependable, knowledgeable support and a solid development road map

    The Solution

    After looking at four possible testing solutions based on products listed in Gartner’s Magic Quadrant, SimplyHealth decided on Mobile Labs deviceConnect to manage mobile devices for testing software. This on-premises cloud solution provides the accessibility and flexibility of the cloud and the security of on-premises technology, protected by the security measures available to the enterprise for its other assets, such as firewalls.

    The physical installation largely amounts to a mobile cart and rack for plugging in many different mobile devices for testing. “DeviceConnect enabled SimplyHealth to have a product-agnostic virtual lab so we could all easily test software on the devices using our own in-house testing scripts,” Dale said.

    Mobile Labs was willing to configure and demonstrate a proof of concept mobile device web application test setup using deviceConnect to show the SimplyHealth team how it worked to manage apps and devices for testing. “After we thoroughly evaluated this configuration, we concluded that Mobile Labs deviceConnect was the best choice,” Dale said.

    Implementation

    Mobile Labs implemented the entire solution for SimplyHealth, from setup to installation to ensuring it integrated well with SimplyHealth’s existing Hewlett Packard Enterprise testing tools, Dale noted. “We were immediately writing automation scripts to use with it. We had it working in production the next day.”

    All affected teams and departments have fully adopted and use the Mobile Labs tool, including testing, development, branding, user experience and support teams, he said.

  • Scania: Adopting DevOps for Auto Production

    Scania: Adopting DevOps for Auto Production

    When you think of large vehicles, chances are you think heavy-duty front and rear axles, suspensions and cab parts. When you think of large engines, chances are you think crankshafts, cylinder heads, pistons and injectors. When you think of the brains behind a company that produces all this, you should think software and the processes that create it.

    Swedish automotive company Scania was building its software intelligence using large, legacy development approaches, coding entire software packages as a single project. The organization’s teams were couched in silos. Releases were highly infrequent.

    Everything changed when Scania scaled and conquered the partitions and divisions that separated teams and adopted agile practices and DevOps.

    Scania and its Software

    Scania, a large global maker of heavy transport buses and trucks and marine and industrial engines, runs many software departments. Its Connected Services department creates web-based portals, APIs and embedded software that transmits live and historical data transmitted to and from drivers and vehicles for logistics including positioning, tracking, service planning, geofencing and messaging.

    Scania’s move toward DevOps accelerated in the 2012-2013 time frame, when the company combined developers and testers into feature teams and molded its first DevOps practices. The company had a host of development issues before that.

    “Before 2012, we were organized around traditional big software projects, which slowed progress and hindered communication. We had long lived branches and a product release cycle of about three releases a year. Silos existed between Dev, Ops, Test and Marketing,” said Anders Lundsgard, technical architect at Scania Connected Services. By 2013, he added, feature teams were adopting processed based on a strict adherence to Scrum.

    Scania’s Dev and Ops teams were housed in different locations and working separate goals that were not aligned or cohesive. These teams suffered from confused communications and increasing stress as development worked only on new features while operations tried to use the new software in a stable way in production.

    Pivotal Changes

    Everything started coming together when Scania formed feature teams that progressively shouldered more of the responsibility for forwarding code to all environments and making it work. “There was no involvement in this from operations or infrastructure as they supported tooling and automation for on-premise infrastructure and shifted software to a cloud platform,” Lundsgard said.

    Scania ultimately added Perforce Helix, a software configuration management tool. As long as software engineers know that the focal point of their work is checking in their code, the Perforce product can be the single point of storage of any one software component for all projects in the deployment pipelines. This way there are no multiple, correct current versions of any piece of code that could cause confusion. “Perforce has a number of capabilities that help engineers collocate software for reviews and even shelve files as they pass between developers,” says Lundsgard.

    Scania uses Perforce Helix in combination with its continuous integration (CI) environment and processes to improve quality beyond what manual testing could ever accomplish. “The goal is that software engineers check code into Perforce Helix at least daily,” Lundsgard said.

    Scania DevOps Processes Today

    Scania now versions every change and automates builds, tests and deployments, with CI as a central development practice. The company no longer uses feature branches, with everyone adding code directly to the mainline. “We use a microservice-oriented architecture in order that each feature team can manage and own certain services,” Lundsgard said.

    Different teams approach development with varying degrees of DevOps maturity. Some teams deploy software continuously, sometimes many times per day. Other teams benefit from using some manual testing and may not deploy software for a few weeks. “The tooling has enabled all teams to have a fully automated process for pushing their code into all environments if they choose—automatically or via a click of a button,” Lundsgard said.

    Remaining Challenges

    Scania next plans to fully automate every component of infrastructure from the network to the servers. “Some of our infrastructure and operations people have started to adopt infrastructure as code and they version that code in Perforce Helix as well,” Lundsgard said.

  • Echidna Takes DevOps to E-Commerce Site Creation

    Echidna Takes DevOps to E-Commerce Site Creation

    The Echidna e-commerce firm installs and evolves e-commerce platforms, providing ongoing development so its clients can leverage e-commerce experiences to the satisfaction of their customers. “We apply carefully selected user experience technology, marketing and analytics abilities to our clients’ strategic goals to do this,” taking what it calls an “anti-Big Bang” approach to continuous deployment, says Mike Pierce, CTO of Echidna.

    “Traditional e-commerce deployments were often Big Bang deployments that people developed on the basis that they had to pressure the business leaders into feeling like they had only one chance to pack as much scope as possible into a large software development project. That approach voids any practical innovation,” says Pierce. With that mindset, it can take years to finish e-commerce sites, and e-commerce companies can go out of business by the time they actually finish such a site, since it would be far out of date by then.

    Echidna sees continuous deployment as one piece in a much larger agility play designed to ensure that businesses compete in digital economies, now and in the future. Continuous deployment is the ultimate goal of DevOps, an approach that enables the business to innovate fast enough to maintain the business’ sharp marketplace edge through acute, turn-on-a-dime competitive dexterity. “In order to do this, continuous deployment helps companies learn to develop high-quality software and deploy it on a rapid, reliable and repeatable schedule,” says Pierce.

    Continuous Deployment Timelines and Challenges

    Depending on the client, its needs and the features in the pipeline, Echidna deploys software to each e-commerce platform from monthly to daily, and at intervals in between those extremes. Echidna seeks to increase the degree of automation of each deployment over time. The challenge is that with so many different clients and platforms, Echidna must achieve its automation victories for each customer individually, solving similar and unique issues. “We are finding our greatest success using PaaS (platform-as-a-service) e-commerce platforms like Four51 because it eliminates a lot of the administrative overhead that is typical with deployments to on-premise platforms,” says Pierce.

    The development model Echidna follows to deploy e-commerce sites affects each software component, even though components deploy at different times. “Payment system modifications require significantly different testing—more testing—and we must deploy them much less often than other components. Marketing components don’t need as much regression testing as other software modules and so we can deploy them much more quickly,” he says.

    The most difficult software to move into continuous deployment in an e-commerce platform are the components that integrate deeply into enterprise systems. That is why Echidna advises business customers to use DevOps methodologies to deploy their enterprise production software at accelerated rates. When they do this, Echidna potentially can speed its deployment of the e-commerce platform components that are enmeshed with those production systems.

    The Four51 Path, Through Jitterbit

    Echidna connects Four51’s OrderCloud to the Jitterbit iPaaS integration server platform, a point-and-click integration tool. “This enables us to streamline further integrations and data exchanges with many of the disparate systems in an ecosystem,” says Pierce. Echidna sees increasing continuous deployment orchestration opportunities as more and more third-party application vendors become compatible with these kinds of integration tools.

    Four51 enables an ecosystem of connected digital services and applications where e-commerce uses numerous disparate systems that exchange data and facilitate work streams in the enterprise in question, Pierce says. “As these systems eliminate disparities and we align them on the central integration and deployment standards that we use, there will be increasing opportunities to introduce clients to lean development practices like continuous delivery and continuous deployment.”

    Conclusion

    Continuous deployment is miles apart from what information technology is used to, especially where manual change management and change control are concerned. But once Echidna exposes its customers to continuous deployment, their managers, C-levels and boards soon begin to witness the accelerated software innovation continuous deployment provides and how this makes information technology—and the business—more nimble, both technologically and competitively.

  • Continuous Delivery and Deployment: A Tale of Two Models

    Continuous Delivery and Deployment: A Tale of Two Models

    EnerNOC (Energy Network Operations Center) is an energy intelligence software provider with more than 1,300 employees in its Boston headquarters and international locations. The public firm helps global customers to efficiently consume energy. “Our mission is to change how the world uses energy, helping customers to improve profitability and visibility for better decision-making and sustainability by focusing on how they buy energy and when and how they use it,” says James Nichols, principal engineer and cloud architect at EnerNOC.

    A regular user of Splunk (the company uses other DevOps tools and platforms as well, including AWS and Oracle), EnerNOC has fully automated monitoring in its perpetual drive to move past continuous delivery and on to continuous deployment.

    Embedded in EnerNOC’s story of why it uses continuous development and continuous deployment models is a chapter on its move to fully automated monitoring.

    EnerNOC DevOps Models

    EnerNOC’s DevOps model is in constant transition toward full automation. Currently, it has fully automated deployment, fully automated monitoring and semi-automated quality assurance (QA), which pull the company’s continuous development approaches.

    A change to “builds on commit” of smaller applications within the legacy software monolith at EnerNOC came hand in hand with further automation, targeting what the company calls “trustworthy continuous deployment,” Nichols says. That was the crux of EnerNOC extending itself into deployment automation.

    Wherever the model is not fully automated and continuous in deployment, it remains continuous delivery. “Most of the variance between the approaches is due to aspects of the delivery pipeline that still have manual processes; these parts are usually comprised of the remaining manual testing procedures,” says Nichols.

    Change Control Necessitates Two Models

    EnerNOC develops and maintains mission-critical software that must pass through a change management approval process. This process includes communications within and across the company and customers, as well as user acceptance testing. This is where the manual testing comes in. Only at the end of this approval pipeline can EnerNOC pass the software baton into the hands of production.

    Due to EnerNOC’s tightly yoked systems and the manual testing, change control remains, along with a mix of continuous development and semi-automation with fully automated continuous deployment. “DevOps is a cultural movement as well as a technical one, and so the existing model could evolve with the organization’s quality and maturity evolutions,” says Nichols. If the manual testing and the relationships between systems give way to more fully automated testing and more amenable relationships, QA could more closely embrace full automation.

    Monitoring Challenges/Achievements

    EnerNOC’s application diversity includes hybrid software with a foothold in the Amazon cloud, in EnerNOC’s data centers and on-premises. “We use three tiers on top of Oracle in the data center. In AWS, we use a combination of big data, cloud-friendly and serverless technologies,” says Nichols. Business transaction data traverses many machines that belong to service groups’ stakeholders. “The distributed, decentralized architecture makes troubleshooting, performance management, security operations and production operations challenging,” notes Nichols. Better monitoring was the answer.

    EnerNOC wanted to offer nontechnical users easy access to systems-level monitoring data with transparency into the many systems through a single pane-of-glass dashboard with readily available system notices and troubleshooting abilities. “We would use Splunk to do this and then feedback everything we learned from using Splunk into driving our DevOps and engineering processes into the future,” he says.

    The EnerNOC DevOps performance team built the dashboard that accompanied the Splunk service, ensuring it would register the performance metrics that are of value to the organization. The performance, product management and development teams maintain an awareness of the metrics and receive the related alerts. “The development team incorporates the ongoing metrics early in the development life cycle to improve application performance,” says Nichols.

    EnerNOC first applied Splunk to web logs for operational capacity planning, then used Splunk to give the Ops team transparency into the function of its new real-time data product that was working in production. As new products came on board, the organization added them to Splunk to provide Ops teams with dashboards, at the urgent request of Ops team members.

    Current Status: All Systems Good

    EnerNOC applies Splunk to test and production systems for views into consistency and acceleration. “Splunk is our primary alerting infrastructure for low-level system metrics like CPU utilization as well as for complex business transactions that span multiple systems,” says Nichols. Splunk has eyes on application health, cluster state across machines, expected systems tasks and suspect or known-bad system behavior, as well as the presence or lack of any significant event.

  • SaaS-Powered FlightPartner Fueled by DevOps

    SaaS-Powered FlightPartner Fueled by DevOps

    Private jet charter company FlightPartner is reaping the benefits of DevOps to build a powerful software-as-a-service (SaaS) offering to keep its customers flying high with no delays.

    “FlightPartner does not own any aircraft but rather facilitates the travel needs of clients by offering air charter brokers (agents to the client) access to a global network of private jet charter availability,” says Douglas Schmohl, CEO and founder of FlightPartner. By acting as a global distribution network (GDN), FlightPartner enables access to real-time availability of private jets.

    What TravelPort is to airline seat availability, FlightPartner is to private jet availability, Schmohl says.

    FlightPartner’s cloud-based SaaS manages data exchanges and transactions through a web browser as a web-based service, requiring no client software installs for the brokers or operators. The service uses Angular.js, a “structural framework for dynamic Web apps” to pass data from the browser to a PHP back end. A database and integrated systems back end builds real-time pricing quotes for available private jets, while the payment mechanism supports search, booking and payment, completing the transaction, Schmohl says.

    FlightPartner uses a Laravel open-source PHP framework, which was created by Taylor Otwell and was originally targeted to developing Web applications following the model-view-controller (MVC) architectural pattern. “This framework allows for rapid development, testing and deployment of our SaaS solution,” Schmohl notes.

    SaaS Technical Challenges

    Schmohl and company endured some technical issues as they built FlightPartner software and worked to raise it to the skies where it would eventually soar. Schmohl was committed to following the lean startup practices of Eric Reis, author of “The Lean Startup,” which redefined the roadmap for a startup tech company, Schmohl says. According to the book, one of the first steps in approaching a new business as a lean startup is to try to float a “minimum viable product,” or just enough product or service to test the market demand for it. “This was nearly impossible for us due to the complexity of the air charter marketplace,” he says, so Schmohl had to invest in a more technically developed product rather than a simple solution.

    In the private jet charter industry, with so much change, so many variables, so many players needing access and so many systems that FlightPartner would need to access, a minimum viable product still necessitated numerous external integrations and APIs. “Developmental collaboration to achieve this was difficult at best and developers often pushed code to production only to create more issues with each deployment,” Schmohl says.

    A second technical misstep—and in the absence of formal development structure—Schmohl’s team wrote code to solve specific functional problems one by one. However, the team found that a method for developing one function would conflict with a different method that was used to create another function, and so on. “The constant patching of the front and back end consisted of whatever worked. This code became challenging to manage and scale,” he says.

    Because of these two technical challenges, FlightPartner’s attempts at a minimum viable product and at following a lean startup approach soon were tangled in a mess of spaghetti code and unmanageable methods, Schmohl says.

    FlightPartner Development Pipeline

    Today, development at FlightPartner is much improved. The SaaS and its components start with a local build that the system pushes to a development server in AWS. FlightPartner developers use SourceTree, a Git client and the Git versioning system to manage software versions. FlightPartner uses quality assurance to manage development and to test code, and developers fix errant code and deploy it to AWS using Elasticbeanstalk. “This enables rapid builds and continuous deployment,” Schmohl says.

    Using a DevOps approach to development brings structure to an otherwise-highly dynamic marketplace. “Offering a SaaS solution as a marketplace presents challenges unlike a typical marketplace. Our inventory (aircraft) is fluid in that it moves often and the price changes depending upon location. This operational challenge translates to numerous and constant development with changes in software functionality,” Schmohl notes.

    These are the operational needs that drive software requirements; the developers’ goals increasingly are to meet those requirements so the software seamlessly supports operations. Development uses a priority status to identify and escalate the builds that are most critical to continued, smooth operational activity.

    Results

    FlightPartner’s development process has created a workflow process that minimizes the resources necessary to achieve operational results. Thanks in large part to DevOps and the cloud-based SaaS system, FlightPartner’s GDN has aircraft available for charter in six of the seven continents, including 35 percent of available aircraft located outside the United States, says Schmohl.

  • Our Sprint to Agile Success

    Our Sprint to Agile Success

    Adoption of the agile methodology is essential to the success of a DevOps culture. This is not revolutionary, but is an important foundation.

    We view agile as the tool for developers to achieve DevOps. Our team, which is developer-centric, is focusing on the agile piece of the equation moving forward.

    But what happens when you think you have a grasp on the agile methodology but it turns out you were completely wrong?

    A change is needed.

    Getting back to the Agile Manifesto is a great starting point. This is our story of DevOps failure to success by implementing the correct agile methodology.

    Our Perception Was Wrong

    When thinking about the agile methodology, and, to a greater extent, DevOps, open communication is at the core. However, it is not the only thing agile and DevOps is.

    At the beginning, we thought as long as there was open communication we were agile. Seeing as we sat in the same room, this was pretty simple. But we quickly learned that this was not agile, and the revelation was painful.

    As we experienced development bottlenecks and difficulty in defining responsibilities, we knew there needed to be an adjustment in how we viewed the agile process. Also, we had begun adopting projects in areas where we did not have a high level of expertise.

    This is what brought us back to the drawing board.

    Getting back to the basics meant looking at the reason for implementing agile in the first place. For us, it was releasing better software, more often, with fewer updates. In detail, it was looking at how long it took the team to identify and define the need. Then, it was looking at how long it took from problem definition to software release. We consider this one software cycle.

    The reason for implementing agile is to decrease the time it takes to move through one of these cycles, as well as to decrease the number of cycles on any one project. Defining this process to the team is how we brought our software development back to the basics.

    Renewed Focus

    Once there was a renewed focus, it was time to implement a set of tools and processes. The concepts we focused on incorporating are the following:

    • Adoption of sprints
    • Open communication
    • Version tracking
    • Environment of continuous testing
    • Responsibility definition

    None of these are particularly revolutionary, but when implemented effectively, it made a world of difference. Once we defined these five areas of focus, we adopted the daily sprint meeting. This implementation was the core of our transformation into a truly agile environment.

    The Daily Sprint Meeting

    In the developer environment, meetings can be against the team culture, especially in a startup. This is why a meeting needs to be strategic. The daily sprint meeting should have both a question constraint and a time constraint. The result is no dragging meetings.

    The two metrics for the daily sprint meeting are: 1) each team member gets two minutes to speak, and 2) four questions need to be answered. Those are:

    1. What did I accomplish yesterday?
    2. What will I achieve today?
    3. What obstacles do I face to accomplish my projects?
    4. How am I feeling today?

    With a team of five people, this meeting should take 10 minutes at the beginning of each day. The adoption of the daily sprint has helped us achieve a level of focus not possible without it. This focus has produced increased productivity, as well as adopting an effective agile environment.

    The daily sprint meeting is how we successfully implemented a DevOps culture. This has made all the difference within our team.

    About the Author/Logan Rivenes

    LRivenes PictureLogan Rivenes is a Marketing Manager with Datapath.io, specializing in decreasing latency through network traffic optimization for DevOps.
    Twitter: @loganrivenes

    LinkedIn: https://www.linkedin.com/in/logan-rivenes-01a8964a

  • Case Study: Pearson Weaves ThreadFix into AppSec, Part 2

    Case Study: Pearson Weaves ThreadFix into AppSec, Part 2

    In part one, we discussed how education content publisher Pearson applied ThreadFix to its AppSec request workflow needs. Here’s the rest of the story.

    The ThreadFix Implementation

    Senior software security engineer Matt Tesauro added ThreadFix to Pearson’s workflow in the following steps:

    1. Using FPM, Tesauro created a Debian Linux package internally to deploy the ThreadFix Tomcat Package (ThreadFix also offers its own Debian package for this).
    2. Tesauro hooked ThreadFix into each of Pearson’s toolsets using the tool scanner file formats ThreadFix understands.
    3. Using the importers built into ThreadFix, Tesauro connected it to the Checkmarx, Veracode, BurpSuite, ZAP, WhiteHat, AppScan and Qualys testing tools Pearson uses.
    4. To make that happen, Tesauro pointed ThreadFix to an API.
    5. Tesauro then set up an API key.
    6. The system was then set to fetch the test results.
    7. If necessary, Tesauro wrote glue code to upload the results to ThreadFix.

    Pearson used ThreadFix to normalize and de-dupe what had proceeded from manual assessments, dynamic scans on applications and static code analyses of source code, directing those outputs into ThreadFix. “So if a static tool and a dynamic tool both found the same cross-site scripting issue, we fed those into ThreadFix, which de-duped those and gave us just one issue to report so that we didn’t bury two teams with fixing the same single coding error,” says Tesauro.

    “ThreadFix became the one source of knowledge for all of the output of our team, which for us is the security vulnerabilities we find in the applications that we either created, bought or had a third party create,” says Tesauro. That enabled Pearson’s AppSec team to feed tickets into JIRA of backlogs from development teams, which made it easier to produce metrics and do reporting. ThreadFix made it easier to feed data into governance, risk, and compliance tools such as RSA Archer. “That enables visibility into work in progress and workflow and into areas of the business that affect AppSec’s work,” Tesauro notes.

    Additional Capabilities with ThreadFix

    Tesauro eventually expanded ThreadFix to other departments beyond AppSec to benefit from its capabilities and the metrics it could produce regarding app progress.

    Tesauro notes a point between the “Bag of Holding” and ThreadFix in the AppSec pipeline that required some work. He used a StackStorm orchestration and layered ChatOps on top to enable new developer capabilities at that point in the process.

    “Now you can go into our private channel and use HipChat to ask the system, for example, to set up Checkmarx for a particular application in a particular business unit. You give it the URL pointer to that unit’s Git repository and off the system goes, setting up the application profile in the Bag of Holding and in ThreadFix and then talking to Checkmarx to set up weekly scans of the code that sits on the master branch. It set that all up in a minute,” says Tesauro.

    HigherEd was the first additional group inside Pearson to benefit from ThreadFix metrics. One such metric was a 44 percent decrease in time-to-fix after adding a JIRA integration into the mix, according to Tesauro. “Once we started producing those numbers, we had a lot of other business units ask, ‘Hey, why does HigherEd get these great time-to-fix numbers? We want them too for our apps.’ It was a great way to get buy-in,” says Tesauro.

    Further Results

    AppSec saw a 5x increase in throughput for the request workflow and went from 44 application assessments in 2014 to fewer than 200 in 2015, Tesauro notes.

    “In 2015, we lost two and a half people and still sped up the process,” he says.

  • Case Study: Pearson Weaves ThreadFix into AppSec, Part 1

    Case Study: Pearson Weaves ThreadFix into AppSec, Part 1

    Pearson is a publisher of education industry content to meet the needs of teachers and students from kindergarten/early learning through higher education and continuing education (for professionals). The company uses a mix of software, from legacy third-party software and “classic ASP apps that are on life support to auto-scaling systems on Amazon,” says Matt Tesauro, senior software security engineer at Pearson. “It’s a very diverse development environment.” Which meant it was no easy task keeping it secure.

    Pearson Before DevOps

    Prior to adopting DevOps, Pearson was bogged down by manual processes, especially in application security. “People sent requests buried in email or, if you were lucky, in a Google spreadsheet. There were very few clear lines and hand-offs between the different activities that were the responsibility of the AppSec group,” explains Tesauro. It was a very manual, custom approach in terms of request handling: someone would respond to a request with an activity, which would require a report that was then emailed.

    At the time, Pearson had no single, well-established methodology or workflow for these activities. There was no particular look and feel or design for creating dynamic, manual or static assessments. There was no list of inputs into the process or outputs to expect at the end of the process. “At best, everything flowed in an ad hoc fashion,” says Tesauro.

    Then, about two years ago, Tesauro and a senior-level peer at Pearson attempted to prioritize those apps the company most needed to assess for security and related issues. They had hoped and planned it would be about 10 apps, to keep the number and the workload manageable. For political reasons, they were able to settle on no fewer than 64 apps that needed appraisal. “We ended up being able to assess only 44 out of the 64 top apps. There are 2,000 and some-odd apps at Pearson, in rough numbers. Just the scale told us we were going to fail in the long run,” says Tesauro.

    Ramping Up to Change

    To resolve this app assessment challenge, Tesauro looked to institute DevOps and Build Pipeline approaches to lay the groundwork for eventually integrating security into the various development teams at Pearson. “I made equivalents of DevOps and Build Pipeline approaches for how we did work in the AppSec program at Pearson,” says Tesauro. These included standard methods of input and intake of service requests similar to how the business produces software development targets for a DevOps shop to hit. That’s when Pearson began to work on instituting and leveraging ThreadFix.

    “ThreadFix was one of the first two parts of that pipeline,” he says. The other part of the AppSec pipeline solution was what Tesauro calls the “Bag of Holding,” a mechanism and repository for tracking all the team-to-team interactions and work assignments. That feeds into ThreadFix.

    During that time, and for about the first half of 2015, Tesauro and a teammate automated a number of manual steps by creating code to perform the “mindless work” so developers could concentrate on their core business instead. “Now when the static code analysis tool Checkmarx finishes its analysis, it generates a report, washes the directory and pushes the report into ThreadFix,” says Tesauro. He also automated a number of other test applications and tools.

    Stay tuned for part two of this case study, coming soon.