Tag Archives:DevOps

Now is the time to share your DevOps story!

IBM Think 2019 call for papers is now open!

https://www.ibm.com/events/think/call-for-speakers/

With IBM Think now accepting abstracts from people wishing to share their stories at IBM’s premiere conference, I thought I would share some “tips” & “tricks” on how best to get your story accepted. Following these ideas is not a guarantee that your submission will be accepted but it will certainly increase your chances.

Submitting a well-crafted abstract

Call for papers submission applications typically have char/word counters on several fields where you are expected to share your idea. Don’t waste that valuable space using meaningless words or phrases. Opening an abstract proposal with “Attend this session to …” just used up 22 characters or 4 words! My advice is to be concise, be clear, be clean, be complete – avoid repetition, extraneous jargon, and excessive buzz words. If you use an acronym, spell it out the first time. Don’t leave people playing the “alphabet soup” game trying to figure out what the acronym means. And finally, please please please…. proof read your submission. Bad grammar and misspellings make an abstract hard to read and creates additional editing work for the selection committee. Don’t make rejecting your submission easy for them.

Structuring your abstract submission

Having read many thousands of “Call for Paper” submissions, people often spend too much time writing what I will term as “the fluff”. This “fluff” often leaves the selection committee wondering when the abstract writer will be getting to the point or if there is a point to be made. In my opinion, a well-structured abstract should clearly speak to these 3 questions (at a high level):

What was the specific problem/challenge you faced?
How did you solve it?
What measured “actual” business results did you achieve?

As some examples:

Increased deployment frequency by 40% or even better, improved release capabilities from 3 months to 1 month
Increased deployment success by 80%
Reduce mean time to recovery by 25%
Reduced testing cycle from 2 months to 1 week

Lastly, the abstract should close with a commitment on the 2 or 3 things you promise to deliver during your session and what the attendee will leave with.

Be prepared to deliver on commitments made in your abstract

Too often, there is disconnect between the submitted abstract and presentation delivered. The result is often a dissatisfied audience leading to poor session rating, poor Speaker rating or both. In some situations, the selection committee may look at past results and previous Speaker ratings to provide insight on who will deliver the best content. My best advice is to follow Stephen Covey’s guidance and “begin with the end in mind”. The details of your abstract are your commitment to the audience. The more concise your abstract is, the easier it is to build the presentation and meet the expectations of the attendees. Happy attendees translate into higher sessions ratings and Speaker ratings.

So, let’s think positive for a moment. You have just received your acceptance notification. Next step is to build that demo asset, workshop curriculum, or presentation. What details will you include in the session material?

My suggestion; quickly build the session outline as a straw-man using bullet points:

Present the problem and explain the solution – in detail! I have walked out of many sessions where the problem was clearly stated, the Speaker said they fixed it sharing how smart they were but offered no insight on how the problem was resolved. I wanted details!
Share assets that helped solve the problem. If you write a utility or code snippet that could add value to others, share how you went about developing the utility or share the code with the audience.
Proudly display your tool chain no matter how simple or complex. In fact, tool chain slides often get the most photos taken. HINT: Be sure to stand close to the screen, be part of the picture and enjoy new found social media fame! For some reason, people love to tweet pictures of others’ tool chains!
Talk about what worked, what didn’t, experiments performed, and lessons learned. DevOps is about continuously learning, experimentation, and failing safely. Be fearless in sharing. Your experience and expertise can save others time and garner respect for yourself with peers.
Introduce what you may do next to become even more effective. DevOps is a journey. Having that longer-term vision and sharing that vision with others may spark a new collaborative relationship with someone who has a common interest in finding the solution.
Present concrete measured (qualified and quantitative) results – tied to the business. DevOps is about delivering results to the business. Sharing your results can help others see the possible and the potential outcomes.

Now that you can envision what the end looks like, work backwards and write the beginning – the abstract you are going to submit.

Remember people are coming to learn from your experiences – you are the teacher. And like Teachers, Speakers have a responsibility to connect with each attendee and work to share a piece of knowledge with everyone in the room. This is your chance to shine and share your expertise with others.

IBM Think 2019 DevOps stories we are looking for but are not limited to…

Continuous delivery and continuous testing on the mainframe
Increasing DevOps maturity: Value Stream Management
Deploying containerized applications with UrbanCode Deploy
Solving the DevOps “Day two” problem
Cultural transformation to achieve desired business outcomes
Deploying hybrid applications in hybrid environments
Virtualizing containers and other software dependencies for the purpose of testing

And be creative! Session delivery doesn’t need to be “death by slide ware”. I encourage those submitting abstracts to think about how they might get “outside of the box” delivering their story in a new and fresh innovative way.

IBM Think 2019 Call for Papers closes July 16, 2018.

https://www.ibm.com/events/think/call-for-speakers/
Why wait? Submit your ideas today. And good luck!

Thanks for reading
Al

Al Wagner is an IBM technical evangelist with more than twenty years of practical field experience in development roles driving thought leadership, strategic initiatives, and tangible solutions around DevOps and continuous delivery. Focusing mainly on deployment automation and continuous testing, Al has practical knowledge of the IBM DevOps solution having assisted, mentored, and enabled both internal IBM and external customer teams to solve their IT challenges. He has spoken at numerous conferences around the world on software development –principles & techniques – and authored/co-authored numerous papers and books including Application Release and Deployment For Dummies, Continuous Testing For Dummies, and Service Virtualization For Dummies.

Speeding application delivery by ~94% with IBM UrbanCode Deploy software

Continuous Delivery DevOps IBM UrbanCode Deploy

Daimler Trucks NA put application developers in the driver’s seat by using a DevOps model and IBM® UrbanCode® Deploy software to manage application delivery, speeding application deployment and improving quality and control.

Daimler Trucks North America needed to replace its fragmented and slow application development and deployment process to meet the ever-increasing demand for IT applications.

Transformation

Daimler Trucks NA implemented IBM UrbanCode Deploy software to support a DevOps application delivery model. Developers manage their applications from coding to automated deployment and rollback.

Results

Business challenge story

Meeting business demand

As with most organizations today, the IT Services team at Daimler Trucks NA faced an ever-increasing demand for new applications to support the business. The department set a long-term objective to find the tools and talent to automate as many software delivery processes as possible. One area ripe for innovation and automation was application deployment.

The company’s application deployment model had become unsustainable for several reasons. First, the software build and deployment processes were independent functions in separate departments. Once the build team wrote the code, it relinquished responsibility for the application’s deployment, essentially “throwing the package over the wall.”

Nick Wylde, Technical Analyst for IT Services and Customer Support and DevOps Champion at Daimler Trucks NA, describes the situation: “After installing an application, the middleware team might get a midnight call from someone because it didn’t work properly. Even if the culprit was a coding problem that belonged to the developers, the middleware team was in the hot seat to make it work.”

Second, the deployment process was slow and error-prone. When the middleware team received the application, it followed a manual work document with more than 30 steps. If someone did any one of the steps incorrectly, the individual had to go back to that step and redo the process. The result: each deployment, whether initial installation or update, took at least an hour, often longer. Further, there was no clear, automated rollback path, so fixing the issue required more manual effort from the deployment team.

Finally, there were few enforceable rules or policies regarding file handling or traceability to source control. This lack of governance could easily introduce errors into existing or new applications as files were manually passed from one server or application to another.

According to Wylde: “Poor or buggy application deployment and slow fixes have a negative business impact. For example, there’s a ripple effect if an application that manages dealership parts inventory is flawed. Trucks get stuck in the shop and can’t go out. The fleet is paying for trucks that aren’t making money, and we lose money because we can’t sell the parts.”

“With IBM UrbanCode Deploy, we’re putting developers in the driver’s seat. They manage the process. They own the application; it’s their product.”

—Nick Wylde, Technical Analyst for IT Services and Customer Support, Daimler Trucks North America

Transformation story

Driving toward a DevOps model

Daimler Trucks NA decided to move toward a DevOps model, which focuses on application-deployment automation. According to Wylde, the first rule of the DevOps model is “you build it, you own it. Developers become the owners of their applications instead of just passing them down the line to the middleware engineers to deploy and troubleshoot.”

Seeking a tool that would integrate seamlessly with its existing software platforms, the company chose the IBM UrbanCode Deploy application-release automation solution. UrbanCode Deploy software supports a DevOps approach to orchestrate, automate and deploy applications, middleware and database changes to distributed data centers, cloud and virtualized environments as often as needed—either on demand or on a schedule. It combines robust visibility, traceability and auditing capabilities. Daimler Truck NA chose an on-premises installation in its data center, but the solution is also optimized for IBM Cloud™ deployment.

“We looked at other products. They simply could not meet the full scope of what we needed to do. They didn’t talk to WebSphere®; they didn’t integrate with other platforms. They couldn’t do configuration. We were looking for a DevOps solution and UrbanCode Deploy was the only product that met all our criteria,” says Wylde.

UrbanCode Deploy software lets developers code and deploy at will. “It gives the keys to developers, who become truly responsible for their product,” notes Wylde. The solution also has an automatic rollback function. Wylde comments: “If the developers push an application forward and it doesn’t work, the middleware team doesn’t get the call in the middle of the night. The developers get that call. They own the application, bugs and all.”

Results story

Saving time, improving quality and control

The UrbanCode Deploy solution helped Daimler Trucks NA reduce application delivery time and downtime because of faulty applications. It also improved application quality, control and governance. By so doing, the company decreased overall application-management costs.

In the first year after implementing UrbanCode Deploy software, the IT Services team used the solution for 3,000 deployments of four applications. By cutting deployment time from 60 – 90 minutes to as few as four minutes, Wylde estimates that automation saved the department more than 3,000 hours. “If a typical deployment took 70 minutes, and we can now do it in four. That’s around a 94 percent time savings for each deployment.” Daimler Trucks NA now uses the UrbanCode Deploy solution for over 100 applications throughout the company.

At first, the team had to clean up existing code before it could use the UrbanCode Deploy solution for subsequent application deployment. Now, a build tool that works in conjunction with UrbanCode Deploy software helps ensure that applications are properly built and will work correctly, putting the onus for coding quality back on the development team.

Wylde also believes that the software is further helping improve application quality because the development team can roll back applications and quickly find and fix problems. “Before UrbanCode Deploy, we might wait for two, three, four weeks before releasing a new patch. With an automated rollback feature, we can release a patch within a couple of days.”

Daimler Trucks NA also uses UrbanCode Deploy software to enforce policies, such as prohibiting manually handling or changing a file. “Everything has to come from source control, unlike before,” says Wylde. “We also have one single template that’s used to deploy all applications,” thus improving governance and control over applications and data.

Other IT departments within Daimler Trucks NA and its sister companies within Daimler AG are interested in Wylde’s results. “There’s a ripple effect. People have seen our success and are paying attention. They realize we can do deployments in as little as four minutes, instead of an hour or more, and they want to adopt our model in their department.”

Wylde believes that a DevOps model, supported by the UrbanCode Deploy solution, is helping change his organization’s culture, particularly among developers. “People like to create things. They don’t want to be stuck doing manual labor. That’s what UrbanCode does,” states Wylde. “It’s not meant to replace user-interface skills, coding development or the creativity in code. It’s meant to replace the manual tasks that add absolutely no value to us in IT, to our customers or to the business.”

Wylde continues, “We’re breaking down the old barriers between developers and other IT professionals within the company.” Plus, his middleware team doesn’t get calls in the middle of the night asking them to fix coding problems. “I would say that anyone using DevOps and UrbanCode Deploy should be ready for a big culture change and shift and, frankly, happier people at the end of the day.”

By aligning DevOps technology with the right people, Wylde is streamlining the organization and focusing on innovation. “We can start to shift toward more creative things like predictive analytics, data mining or other things that truly bring value,” he says.

Wylde concludes: “Companies that don’t adopt a DevOps model risk going the way of all those now-defunct video rental and electronics store chains that didn’t change, or didn’t change fast enough to keep up with technology transformation and customer expectations.”

About Daimler Trucks North America

Based in Portland, Oregon, Daimler Trucks NA is North America’s premier heavy-duty truck manufacturer. This subsidiary of German automaker Daimler AG has been producing best-selling brands of long-haul and cross-continent trucks for more than 70 years. In addition to its familiar Freightliner brand, Daimler Trucks NA makes commercial vehicles under the Western Star nameplate and manufactures school buses under the Thomas Built brand. The organization employs approximately 20,000 people and has roughly USD 5.3 billion in annual sales.

Take the next step

To learn more about the IBM solutions featured in this story, please contact your IBM representative or IBM Business Partner, or visit the following website:

Continuous Release beta now available

Bluemix Continuous Release DevOps

The beta version of the IBM® Cloud Continuous Release Bluemix® service is now available. Continuous Release in an enterprise-scale release management tool that makes it easy to combine on-prem and cloud-native tools into a single release event. You can, for example, combine Continuous Delivery pipeline tasks with UrbanCode Deploy tasks in a single deployment plan.

With Continuous Release, you can automate as much of your release process as you need. Combine manual tasks with automated tasks that manage Continuous Delivery composite pipelines and UrbanCode Deploy applications. Other task types automate email messaging and Slack notifications.
Continuous Release logo

Beta features

Some of the beta features include:

Teams use releases to collaborate on multiple deployments and events.
Coordinate releases across multiple Bluemix organizations.
Combine Continuous Delivery composite pipelines and UrbanCode Deploy applications in a single deployment plan.
Use the calendar to manage release milestones and blackout windows.
Import and customize events and releases.

Bluemix beta services

Like many Bluemix services, Continuous Release went through an experimental phase before the beta release. During the experimental phase, users were free to try the service as new features were added at a steady cadence. With the beta version, Continuous Release is still free and limited support is now available. If you haven’t already, open a Bluemix account–it’s also free. Early adopters can influence product direction with their feedback.

Take a taste before you order the platter: Canary deployments in IBM UrbanCode Deploy

advanced deployment techniques blue-green canary DevOps

Even when everything is going well and you’ve got continuous deliveries running like clockwork, it’s still a leap of faith to update your production environment. Any problem immediately becomes a big deal when it’s in production and might affect everyone who is using the application. That’s the main reason for canary deployments — the practice of deploying to one or a few nodes first, and then sending a few customers to try out the new version before you make the leap to sending all customers to that new version. It’s like getting a taste of some new food before you commit to it entirely — always a good idea when you’re experimenting!

I’ve got a document here about Deploying applications with canary nodes for more detail, but at a basic level, all you have to do is tag your canary node or nodes with a resource tag like “canary,” and then set up your processes to deploy to that tag first.

You can put the canary tag on resources either in the resource tree or in the environment resource mapping. Just click the tag icon next to an agent resource and pick a tag:

Then, in the application process, you can use a For Each Tag loop to deploy first to the canary tags, run some automated tests, and then run over the other resources. I’ve listed a few ways of doing this in Deploying applications with canary nodes, but one way is to include the deployment steps as part of the For Each Tag loop with some automatic tests and rollback steps. The following process deploys my application, runs tests on it, and rolls back if anything goes wrong:

Those steps are all inside a For Each Tag loop, so when I run the process I pick the tags to run on and the order in which they run. So I just select the canary tag first, and then select whatever other tags I have on the other nodes:

That’s all there is to it, at a basic level. You can set up the tags and processes any way you want to deploy to a test system before you take the plunge. For example, if you’ve got database nodes and application nodes, you can set up one node of each to be the canary system.

For more details, see Deploying applications with canary nodes. I’ve also included canary nodes as part of a larger scenario in Setting Up Blue-Green Deployments in IBM UrbanCode Deploy 6.2.4.

Deploying applications with canary nodes

advanced deployment techniques canary DevOps

When you’ve got an application running on multiple nodes, it’s usually a good idea to update a few tester nodes first, before updating every node. That way, you can make sure that the new version of the app is running as you expect on the canary nodes before you commit to updating every node. You can run any automatic or manual tests that you want, tracking the users who are sent to the canary node, before you update the other nodes. If something goes wrong on the canary nodes, you can cancel the upgrade and continue using the nodes that haven’t been upgraded.

I include a canary node as part of a blue-green deployment scenario in Setting Up Blue-Green Deployments in IBM UrbanCode Deploy 6.2.4 and the related video, but I’m going to explore canary nodes here in a little more detail.

There are a few ways to set up a node as a canary node in IBM® UrbanCode™ Deploy, but the way that seems the most straightforward to me uses resource tags. Resource tags are labels that you assign to resources, particularly agent resources. With resource tags, you can identify groups of agents in any way that you want. Then you can run processes on only the agents with a specific tag. So, to deploy to a canary node or nodes first, give them a tag such as “canary” and set up your process to deploy only to those nodes first. If the canary deployment goes well, you can then deploy to the rest of the nodes.

Setting up the canary deployment

As you might have guessed, the first step is to apply the resource tags to the resources in the environment. I’ve used the tags “canary” and “mainSystem” that I used in the blue-green deployment demo in the following application environment. It’s got one canary node and two non-canary nodes.

Here’s how the topology looks:

A simple way to deploy to nodes by tags in IBM UrbanCode Deploy version 6.2.4 is to use the For Each Tag step. This step is a loop that runs over all resources that have the given tag or tags. For example, here’s a simple application process with a For Each Tag step. Inside the step is a sub-process that runs for each resource that has the specified tag or tags.

In the loop properties, I select the tags to run on. Here I’ve selected just the canary tag, but I’ll show you how to change that later.

That’s it; the server knows to run the steps in the loop on only the resources with matching tags. So, to deploy to my canary node, I start the application process, give it the new versions of the components as usual, and leave the default canary tag in the process request:

The process updates only the nodes with the canary tag; in this case, only one of the three nodes is updated. After the process runs, the inventory and compliance for the environment show that only one of the three nodes is running the requested version. That’s what the request intended to do, but it still means that the environment is noncompliant because not all nodes match the process request.

But the flexible part is that I can change the tags for a specific process request. When I’m ready to move all nodes to the new version, I run the same application process again, giving it the same version but the mainSystem tag instead of the canary node.

Now all nodes are up to date and the inventory is compliant:

That’s a simple way to run a canary deployment with resource tags. That method is fine if you don’t mind the manual work of requesting the same application process twice. Automating everything into a single process is better because I know it’ll run the same way every time. So here are two ways to update both the canary nodes and the main nodes in a single run of an application process:

Using two tags in the For Each Tag step

One way to deploy to both tags in one process is similar to the way I handled the canary node in the article Setting Up Blue-Green Deployments in IBM UrbanCode Deploy 6.2.4 and the related video. If you don’t want to have to run the process twice, you can set up the application process to update the canary node first and the rest of the nodes second.

One way to do that in a single process is to include automatic or manual tests as part of the For Each Tag loop. Then, because the order of the resource tags in the process determines the order in which they are updated, you set the canary tag to run first and the mainSystem tag to run second. This way, the process updates the canary node first, runs the tests, updates the main nodes, and runs the tests again. You can include rollback steps in case any deployments or tests fail. The process can be as simple as a single deployment in one step and a test in another step. I’ve also added a rollback step in case anything goes wrong.

Then, when you request the process, you put the canary tag first and the tag for the rest of the nodes second:

Using multiple For Each Tag loops

Another way is to use multiple For Each Tag loops, with automatic or manual tests between them. In the following example, the first loop handles the canary nodes and the second loop handles the other nodes. You can include any automatic testing, manual testing, or approvals between the loops.

The only trick to this process is that, when I request the process, two loops are shown in the request. I’ve got to remember to put the canary tag in the first loop and the mainSystem tag in the second:

Those are just a few ways of modeling and deploying to canary nodes to make sure everything is working right before you deploy new applications to all of your nodes. Let us know if you’ve got other ways to do this or questions about how to make this work in your scenario.

Announcing UrbanCode Deploy v6.2.4: Better with Cloud & Help for Tricky Deployments

Cloud DevOps uDeploy UrbanCode VMware WebSphere

On March 21, version 6.2.4 of UrbanCode Deploy will be available to our customers. This release addresses two important aspects of the product:

UrbanCode Deploy is better with Cloud… and …

UrbanCode Deploy continues to address tricky deployments.

In the first category, “Better with Cloud,” in version 6.2.4, the UCD Blueprint Designer adds Google Cloud to the growing list of supported clouds: SoftLayer, AWS, Azure and Openstack clouds. The team has also enhanced the UCD Blueprint Designer’s integration with VMWare:

For VMWare vCenter provisioning, support has been added to allow using customization specifications, provisioning software without cloud-init via VMWare tools, and the ability to use both static and DHCP networking constructs.
For VMWare vRealize Automation (vRA), the blueprint designer supports adding additional disks to a virtual machine definition, leveraging custom machine prefixes, and enhanced validation and support for deployment request properties. Why use UCD with vRealize? That way you get the best of deployment usability and the best integration with VMWare.

UrbanCode Deploy is well positioned to enable its users to benefit from a hybrid IT environment where deployments take place in cloud environments, to on prem data centers and the mainframe.

This new version of UrbanCode Deploy exploits the power of cloud computing with the new DevOps Connect plugin. The new plugin enables mobile app usage for UrbanCode Deply and reporting functions never before available. Use the plugin to:

Enable an UrbanCode Deploy mobile app for your smartphone. With the UCD mobile app you can monitor the status of deployments and manage approvals, all from you iOS smartphone.
Connect to the currently free, experimental reporting solution for UrbanCode Deploy named DevOps Insights, which will enable you to monitor deployment metrics such as throughput, and cycle time.

Version 6.2.4 of IBM UrbanCode Deploy addresses “Tricky Deployments” with usability improvements that make rolling deployments across servers easier. You can now specify how many servers to deploy to at a time within an environment, providing better control of changes across servers. Deployment Processes can now run against specific (and multiple) tags, reducing process creation overhead, and greatly simplifying Blue/Green, Dark/Light, and other advanced deployment techniques. See more info in a blog on this topic.

Tricky Deployments are further supported by plugins which provide processing and integration functions. UrbanCode Deploy updates and releases new plugins continuously, averaging about two new plugins a month! With this announcement, we recognize new plugins that support IBM, third party and open source products:

New plugins

IBM Operational Decision Maker source configuration
Microsoft Silent Installer support for UCD v6+
Additions to the UrbanCode Open Development community: https://developer.ibm.com/urbancode/plugins/development-community
Rational ClearQuest
Text-Utils
Datical

Updated plugins

Docker Automation, Docker source configuration, and Docker Compose
Artifactory
Jenkins and Jenkins Pipeline
IBM Integration Bus
IBM Rational Quality Manager
Microsoft Team Foundation Server
Salesforce

UrbanCode at Interconnect

If you are going to Interconnect this year, don’t miss the “Continuous Delivery Keynote: IBM UrbanCode Roadmap” Session ID: 6816A, and numerous client success stories, for example “One-Click Deployment Leveraging IBM UrbanCode at Physicians Mutual Insurance” ID: 1660A.

If you are starting to think about migrating from WebSphere Application Server v7 or v8 to WebSphere Application Server v9 due to the announced end of support for versions 7 and 8, don’t miss these UCD-WAS migration topics:

Migrating to IBM WebSphere Application Server Version 9 with IBM UrbanCode Deploy Wednesday, 9:00 AM – 9:20 AM | Engagement Theater Booth #588 | Session ID: 4318A
DevOps: Using UrbanCode Deploy to Migrate to WebSphere Application Server 9 Bluemix and SoftLayer App Server / Runtimes Breakout Session BAS–3604

I hope to see you there!

Integrating UrbanCode Deploy with Bluemix services

Bluemix Continuous Release DevOps IBM UrbanCode Deploy

In DevOps Connect, use the IBM Deploy for Cloud Reporting plug-in to create integrations that provide UrbanCode Deploy data to the Continuous Release and Continuous Delivery Bluemix services.

Prerequisites

UrbanCode Deploy requires a patch to integrate with Connect. For information about downloading and installing the patch, refer to the Overview page.

In the UrbanCode Deploy instance that you want to integrate with, generate a token for the admin user.

Procedure

From the DevOps Connect dashboard, click Integrations, and then click Add New.
In the Name field, type a name for the integration.
From the Integration Type list, select IBM UrbanCode Deploy for Cloud Reporting. Fields that are related to your selection are displayed. The Version field displays the plug-in version number.
In the Server URI field, enter the public URL of the UrbanCode Deploy server. For example, https://my_UCD.example.com:8447.
In the Authentication Token field, enter or paste the authentication token that was generated by UrbanCode Deploy.
In the Admin User Email field, enter a comma-separated list of IBMids to give access to the DevOps Connect web-based dashboard.
Optional: Click Run Integration to run the integration immediately. You can manually run integrations at any time.
Click Save.

Results

After the integration runs, UrbanCode Deploy data is available in your Bluemix services such as Continuous Release, and Continuous Delivery.

Shift Left: Find defects earlier through automated test and deployment

DevOps IBM UrbanCode Deploy Testing

Do you know how much time it takes or how that translates into dollars lost every time you fix a defect in development, QA, or Production? The cost of application failures or errors increases exponentially the further into the delivery pipeline they are when found. If application defects are discovered by end users in Production, or errors cause a Production outage, the cost can be thousands per second, in addition to the intangible loss of reputation.

So how do you begin to identify defects earlier in software development and prevent them from becoming major, costly errors later on? Hear Al Wagner, IBM Technical Evangelist, as he discusses how to “shift left” and;

Incorporate service virtualization and automated testing into development for a more thorough and accurate representation of application quality
Integrate deployment automation with continuous testing to remove wait times on application promotion
Adopt best practices that have proven successful for IBM customers who are currently shifting left

Watch this on-demand webinar today!

Adopting DevOps @ Scale: Lessons learned at Hertz, Kaiser Permanente and lBM

DevOps

DevOps has become a major enabler of business innovation that can drive digital transformation at an enterprise level if done well. Challenges remain, however. Crossing the chasm from successful DevOps pilots with “two-pizza” teams to full enterprise adoption, including cultural transformation, best practices and tools remains a challenge.

Join Alan Shimel (DevOps.com) as he hosts a panel discussion with Hertz’ John LaFreniere, Kaiser Permanente’s Raghunath Raman and IBM’s Sanjeev Sharma on how traditional enterprises are accelerating innovation by adopting DevOps practices at scale across their organizations.

Find out how:

Hertz is accelerating transformation of their platforms, business process and operating models with Cloud, DevOps and Agile.
Kaiser Permanente is managing the cultural, process and integration challenges of multi-speed IT.
IBM has embarked on a DevOps transformation that has engaged over 10,000 developers already — including becoming one of the world’s largest users of GitHub Enterprise.

Register today!