Quantcast
Channel: Deployment Automation – XebiaLabs
Viewing all 59 articles
Browse latest View live

Using XL Deploy and Docker Together: 5 Benefits for Enterprises

$
0
0

Every so often, I hear that you don’t need deployment automation tools when working with Docker. However, speaking for one of those tools—XL Deploy—I can tell you that you’re missing out on many advantages that will make deploying applications in a complex enterprise environment a lot easier.

XL Deploy is a leading deployment automation software for enterprises. Enterprises use XL Deploy to automate and standardize their complicated deployment processes. Docker, of course, is one of the most popular tool ecosystems built in this decade. It has captured the developer’s imagination by providing the right set of abstractions that make it easy to deploy and scale applications.

Docker changes the way an enterprise thinks about applications. With Docker, the application is a unit of shipment. Docker image not only packages the application but also all its dependencies so you can run applications anywhere.

XL Deploy provides a lot of value to enterprises planning to use Docker. Here are 5 reasons why.

1. Unified deployment platform for legacy/existing and greenfield applications

It’s a reality that most enterprises have deployed many existing applications to JBoss, Tomcat, Weblogic, and IIS servers. XL Deploy over the years has successfully helped many enterprises automate their traditional middleware deployments. These applications deliver business value and will be costly to migrate on modern container-based data centers. With the XL Deploy/Docker integration, enterprises can use a single tool to deploy and manage their existing applications, as well as deploy their new, shiny greenfield Dockerized applications. XL Deploy provides high-level orchestration capabilities for all your deployment needs, which can include WAR packages, EAR packages, or Docker images. XL Deploy supports Docker Swarm and Kubernetes container orchestration tools so your enterprise can deploy and scale containers using the container orchestration technology of your choice.

2. Automation of the entire enterprise application workflow

Applications aren’t deployed in isolation. There are many steps that need to be performed to deploy them. For example, prior to deploying an application to a Docker host, you might want to back up a database, apply a database migration script, clean up a directory, and so on. An application might also depend on other applications. Before you deploy an application, you have to make sure all its dependencies are taken care of as well. The order of these steps/dependencies is important. A deployment tool should be smart enough to run some of the steps in parallel and some sequentially. The XL Deploy application dependencies feature allows you to define such dependencies. The XL Deploy orchestration feature provides parallel or sequential execution of these steps. And, because XL Deploy is extensible, you can customize the tool to meet your needs.

Enterprise Software Delivery in the Age of Docker and Other Containers

WHITE PAPER

Enterprise Software Delivery in the Age of Docker and Other Containers

Most of today’s forward-thinking companies are investigating container technology as a potentially better way to deliver software.

Read this white paper and learn about the benefits of Docker and other containers, how to harness the power of containers for enterprise application delivery, and more.

3. Enterprise security and centralized audit capabilities

XL Deploy is not meant to be used by just a single developer. Instead, it is a tool for different people belonging to different departments. In an enterprise, there are a variety of groups (developer, ITOps) that need different kinds of access control. XL Deploy enables role-based access by group—such as development, operations, and management—to support compliance and governance requirements. With one central tool—XL Deploy—you can manage all your processes, automatically capture logs, and easily meet audit requirements. You will be able to answer who owns this container and what is this container doing.

4. Provides portability across container orchestration tools and CaaS solutions.

Currently, XL Deploy supports Docker Swarm and Kubernetes container orchestration tools. XL Deploy provides a higher-level abstraction so enterprises can move their workload to either solution as needed. Going forward, we will support Containers-as-a-Service platforms like Docker Cloud so you can use a single tool to deploy containers to the whole container ecosystem. The advantage is that your enterprise does not have to learn new ways to deploy containers as the target environment changes.

5. Standardized way to handle environment specific configuration.

XL Deploy includes the concept of dictionaries, which contain environment-specific entries for placeholder resolution. This means your deployment package remains independent of environment-specific values. This is useful when you want to maintain portability across different environments such as Docker Swarm and Kubernetes. You can have single package that can be deployed in any target environment.

Conclusion

XL Deploy allows enterprises to transition to the Docker ecosystem at their own pace. It secures their past and gives them the confidence to change their future for the better.

 

The post Using XL Deploy and Docker Together: 5 Benefits for Enterprises appeared first on XebiaLabs.


v7.0 Delivers an Improved DevOps Experience to Diverse Users and Teams

$
0
0

We’re kicking off the summer with a brand new release of the XebiaLabs DevOps Platform! Version 7.0 delivers a little sunshine to both technical and not-so-technical users, making it easier than ever to deliver great software, super-fast, with super scalability across diverse applications and teams.

Version 7.0 rolls up all the terrific features of our last two releases, v6.1 and v6.2, and delivers new ones as well. Below is a quick overview of some of the highlights. You can find a full list of all the goodness in the release notes on our documentation site.

Streamlined Software Release Flow with New User Experience

A new user interface and powerful features deliver significant time and cost savings when applied over many users and teams, and thousands of releases per month. Enhancements include streamlined deployment tasks, new wizards, improved views and reports, and a more granular search. Also added is blackout period management so teams can specify times during which apps cannot be released, such as holidays or end-of-quarter blackout windows.

Improved user interface in XebiaLabs version 7.0

XL Deploy’s new and improved user interface streamlines workflows and improves pipeline efficiency

Targeted, Clear Communications with Flexible Notifications and Alerts

New notification features add flexibility to the way users can be notified of important release events that require action. To avoid “alert fatigue,” teams have detailed control over who receives which alerts so users won’t “tune out” and ignore the notifications that matter most. Plus, teams can choose their preferred way to be notified with more email options, a new “due soon” notification and integrations with popular ChatOps tools such as Slack, HipChat and Pager Duty.

Notifications screen in XebiaLabs version 7.0

The new Notification Settings feature in XL Release offers fine-grained control for sending out notifications on task and release events and for specifying which recipients should receive notifications

Enhanced Release as Code Features for Dual-mode Enterprise DevOps

The dual-mode “Release as Code” capability lets teams define releases entirely with code in addition to using the familiar visual user interface. This feature allows experienced developers to write code instead of using a graphical user interface to quickly create new releases, using the same standard DevOps platform and processes as all other users.

Additionally, releases can be automatically launched from other code-centric tools like Jenkins, or they can trigger activities in such tools. Release templates can now be exported as code, and the code can be previewed in the user interface. Dual-mode capability gives users the choice of code-centric release definition or XebiaLabs’ GUI-centric workflow, letting them work in the way most efficient for them.

Focused Troubleshooting: Release Risk Assessed in Real Time

Enterprise IT teams can now easily tell which releases are in jeopardy with XebiaLabs’ automated risk assessment, calculated in real time for each software release. The platform automatically reviews multiple risk factors to determine an overall release risk score, clearly displaying a green-yellow-red risk status in the Release Overview.

Automated risk assessment in XebiaLabs version 7.0

The automated risk assessment feature in XL Release lets you easily see the status of all your releases so you can quickly spot which ones may be at risk

Enterprise release managers can see at a glance which ones of their tens or hundreds of ongoing releases are in trouble. They can drill down to see detailed risk information on each individual release’s dashboard so they can review and address the issues that have led to that release’s “At Risk” rating. This DevOps Intelligence provides early warning of problems, giving teams time to solve issues and avoid delays before major trouble occurs.

Learn More

Read more about the features of version 7.0 here and in these blog posts:

Try out the XebiaLabs DevOps Platform for yourself here.

The post v7.0 Delivers an Improved DevOps Experience to Diverse Users and Teams appeared first on XebiaLabs Blog.

Why People Are Talking About the XebiaLabs 7.0 DevOps Release

$
0
0

The DevOps and Continuous Delivery community is abuzz with excitement over the 7.0 release of the XebiaLabs DevOps Platform. The latest software update includes a powerful redesigned user interface, along with features such as dual-mode “Release as Code,” real-time release risk assessment, and many other capabilities for delivering better software faster, at scale.

Jason Lenny is Technical Product Director for XebiaLabs

At our recent DevOps Leadership Summit, I sat down with one of the drivers behind the 7.0 release, Jason Lenny, Technical Product Director for XebiaLabs, to talk about the new features and why they matter to the Customer and DevOps Communities.

What is it about the 7.0 release of the XebiaLabs DevOps Platform that is getting the whole community buzzing?

Where to begin here–there are so many incredible features that I’m excited we’re delivering with this release. Within XL Deploy, we’ve completed the new and improved user interface, which introduces streamlined workflows designed to simplify the running of deployments and improve the efficiency of the entire pipeline. Cloud and container migrations are a priority for our customers. That’s why we continue to deepen our cloud and container integrations, enhancing our AWS and Docker plugins and adding new ones, like the new Azure plugin.

XL Deploy's new and improved user interface streamlines workflows and improves pipeline efficiency.

XL Deploy’s new and improved user interface streamlines workflows and improves pipeline efficiency

XL Release has also undergone numerous improvements to areas such as predictive risk analysis, release-as-code, the ability to customize the behavior and appearance of notification emails, the addition of Slack and HipChat integrations, and more control over blackout periods.

What are you most excited about with the upcoming release?

For me, the most exciting thing that we’re evolving in this release is the continued improvements to our predictive risk analysis feature. This is an important piece for DevOps Intelligence, which is necessary for optimizing software delivery and creating a competitive advantage for large enterprises. We’re bringing the risk management paradigm more to the center of the release management workflow, and I’m looking forward to hearing feedback on how this mode of working with releases can improve the ability of teams to make sense out of very complex and mixed deployment landscapes. There’s just so much potential in this area to be a game-changer.

Predictive risk analysis is important for DevOps Intelligence

Predictive risk analysis is important for DevOps Intelligence, which helps companies optimize software delivery and create a competitive advantage

Can you explain this idea of DevOps Intelligence a little bit more?

DevOps Intelligence is the idea that, by combining data in your existing DevOps tools, you can generate (often surprising) insights about what is working well or needs improvement within your process. It bring a consistent, business-level visibility and context to the constant background hum of many small microservice-type deployments. We’ve begun to move our platform in this direction by implementing features like predictive risk analysis in XL Release, but we’ve got much more in store.

Have you seen any early customer feedback on the new release?

The new UI design in XL Deploy has been available for our customers to try out for some time now, and we’re already seeing many users who have reported to us that they started to upgrade on their own accord. It’s always great to get this sort of validation from real customers on a feature we’ve been building!

Can you tell us when and how it will be available?

I am excited to say the 7.0 release is available now through our website, including a trial version you can download to play with all the new features.

The post Why People Are Talking About the XebiaLabs 7.0 DevOps Release appeared first on XebiaLabs Blog.

XL Deploy v7.0 Speeds Up Software Deployment with New UI

$
0
0

Companies of all kinds, from large financial firms to major airlines and retailers, have used XL Deploy for years to dramatically increase their production speed. The latest release of XL Deploy, version 7.0, further speeds up the software deployment process with a new user interface that’s easy to install, easy to learn, and easy to use for your everyday work.

Let’s take a look at some of the cool new features of this release.

Configuration Management and Deployment in a Single Screen

The new XL Deploy user experience starts with the Explorer, a single screen that lets you work with configuration data and perform deployments. No need to switch between different screens to perform your daily tasks. In the Explorer, you can define infrastructure and environments, create and import applications, and kick off a deployment with just a few clicks.

The Explorer also offers powerful search functionality, so you can easily find the configuration items you need to work with.

XL Deploy v7.0 Configuration Management

Deployment – Pick a Target and Go!

With XL Deploy, starting a deployment is always easy: just select what you want to deploy and where you want to deploy it, and XL Deploy does the rest! You don’t have to build a workflow or script out the process; XL Deploy’s model does the work for you.

And the new user interface walks you through the steps. After you choose a deployment package in the Explorer, you can quickly pick the right target environment and go!

XL Deploy v7.0 Deployment Target

The new user interface streamlines tasks and shows the information that you need, when you need it – like dependencies between application versions, the relationship between the parts of an application and the target environment, and any deployment errors that need to be addressed.

And of course, you can still adjust the deployment to meet your requirements. For example, you can change the mapping of deployables to containers, edit properties of deployed items on the fly, and set deployment properties such as orchestrators.

XL Deploy v7.0 Deployment Mappings

Starting the deployment is as easy as a single click, but if you’re not ready to go, you can always review the deployment plan first, or have XL Deploy automatically execute the deployment at a later time.

While the deployment is running, you’ll see the status of each step, including a real-time log of the actions that XL Deploy is executing on remote hosts. It’s the same concept as the old GUI, but with a fresher, more streamlined look and feel.

XL Deploy v7.0 Deployment Log

New Task Monitor Lets You Stay on Top of Your Deployments

In the new XL Deploy user interface, the Task Monitor helps you stay continually aware of everything that’s happening in your system. It lets you keep an eye on active deployments and assign them to users who need to pick them up for troubleshooting – for example, if a deployment fails due to an infrastructure issue or a network outage.

In addition to deployment tasks, the new Task Monitor also shows the status of active control tasks, which are tasks that perform useful admin actions such as checking the connection to a host or synchronizing plugins to a satellite.

With the new Task Monitor, you always get a complete picture of what’s running now and what’s scheduled to run next.

XL Deploy v7.0 Task Monitor

Deployment Reports at Your Fingertips

Why scramble at the last minute to gather data for auditors? The new user interface includes a deployment report that details what was deployed, when and where it was deployed, who performed the deployment, and exactly what actions were taken in the process. You’ll see the exact plan that was executed, even if it includes groups of steps that ran in parallel. And of course, the same goes for undeployment and rollback actions.

XL Deploy v7.0 Deployment Reports

Easily Configure Role-based Permissions

Without granular control over who is allowed to do which tasks, you compromise the security of your entire process. For administrators, setting up and managing user roles, global permissions, and local permissions can be time-consuming work. The new XL Deploy user interface makes the process faster and smoother, with fewer clicks and more intuitive interactions. New User Management screens make it easy to review permissions settings at a glance, so you can be sure that the right access controls are in place.

XL Deploy v7.0 Role-Based Security

What’s Next?

The new XL Deploy user interface gets more powerful with each release. Future releases will introduce valuable features, such as an improved way of viewing deployment pipelines, the ability to discover middleware infrastructure, and more.

Get the New UI

When you upgrade to XL Deploy 7.0, you’ll log into the new user interface by default. Give it a try and let us know what you think!

Not ready to switch? That’s okay. Visit the XL Deploy 7.0 release manual to learn how to continue using the legacy user interface.

The post XL Deploy v7.0 Speeds Up Software Deployment with New UI appeared first on XebiaLabs Blog.

Expedia Gives Developers Self-service Deployments

$
0
0

If you ever travel, chances are you’ve gone to Expedia.com to check out hotel, flight, car and other options. One of the first online booking websites, Expedia, Inc. is now one of the world’s leading travel companies, with an extensive brand portfolio that includes some of the most trusted online travel brands from around the globe.

To continue their market dominance in a very fast-paced market, Expedia, Inc. looked to increase software deployment speeds and streamline processes, while operating at scale across 1,000 machines.

Expedia

The Challenge

Supporting manual deployments, managing dependencies and manually patching code were taking more time than they wanted, and the Operations team knew they could improve and automate. They sought to streamline their use of multiple tools and manual processes.

Using Chef to manage deployment services resulted in too much script-related maintenance. Whenever they needed to update their services or make changes, they manually edited each script and then redeployed their applications to each environment separately. The Operations team knew there was a better way. Rather than spending time manually executing or maintaining deployments, Operations wanted to give their developers self-service, schedulable, automated deployments.

5 Reasons To Stay Away from Workflows - KLP

WHITE PAPER

5 Reasons to Stay Away from Workflows

When it comes to application deployment, “simple ‘n easy” workflows seem quite appealing. However, they suffer from many problems when applied to enterprise deployment automation. Learn why some users choose to use workflows, the drawbacks and why XebiaLabs doesn’t use them.

 

 

Developers Deploy Twice as Fast with XebiaLabs

Expedia considered a range of tools to automate their deployments, including Puppet, Chef, Microsoft Orchestrator SCCM and the XebiaLabs DevOps Platform. They chose XebiaLabs because it manages dependencies, has a model-based, low maintenance architecture and does not require copious custom scripts. Today, over 200 developers at Expedia use XL Deploy to manage, on average, over 2,500 deployments per month.

Within just one month of implementing XebiaLabs, we realized a 20% increase in release velocity, a 33% increase by month two and later reached a 50% increase.

Ganeshram Iyer, Manager of Release Engineering at Expedia

Game-changing Results with XebiaLabs

In addition to a huge boost in deployments per month, Expedia has also achieved many other game-changing results, including:

  • End-to-end automation and control
  • Seamless, self-service deployments for developers
  • More time for Operations team members to excel in other work as they are no longer required for deployment activities
  • Standardized and defined release process
  • Ability to assign permissions, roles and controls to granular aspects of the pipeline as needed
  • Consistent steps across all environments
  • A process that guides developers to adopt coding best practices for all environments

Learn more about Expedia’s processes and the improvements they made with XebiaLabs… read the full case study!

The post Expedia Gives Developers Self-service Deployments appeared first on XebiaLabs Blog.

What DevOps Means for Software Security

$
0
0

Over the past few years, the rise of the DevOps movement has led to a significant increase in developer productivity and accelerated the pace of software delivery. Automation plays a big role in modern DevOps-based software development. In fact, it is the automation in testing and deployment that has enabled companies to do multiple releases in a day, compared to the old times where releasing once a week was considered agile development.

 

DevOps combines elements from multiple disciplines of engineering, QA and operations to define a new paradigm to build software. What does it mean for software security? Unfortunately, most people don’t have a clue and are still trying to shoehorn old security practices into the new DevOps model. Some more enlightened folks are trying to come up with big bang frameworks (similar to the SDLC of yesteryears) to incorporate security with DevOps. SDLC itself is fundamentally different from DevOps as it tries to incorporate a notion of security as gatekeeping between different phases of software development.

Thus, both these approaches are bound to fail for the following reasons:

  • DevOps is not just the sum total of the tooling used for testing, integration and deployment.
  • My DevOps is not the same as your DevOps.

Old security practices cannot be directly lifted and applied to DevOps since it goes beyond just the tooling and process. If you try to automate everything about threat modeling, secure design, secure coding rules, security testing and patch management with every release in the DevOps world, you are setting yourself up for disaster. DevOps is a fundamentally new way to build and deliver software and not a mere combination of all existing tools. You need to make a fundamentally new set of choices in order to assess the security risk of your application.

DevOps also doesn’t lend itself to big process frameworks because, how I choose to implement it may be different from how you choose to implement it. It is the flexibility and lack of rigorous process controls that makes DevOps attractive in the first place. Trying to enforce an SDLC-like process on top of it will not likely find many takers.

It is actually incredibly hard to define what is meant by DevOps without referring to the tools that are commonly used to automate build and deployment. Let’s try and list different facets of DevOps-based software delivery:

  1. The source code of the application resides in a distributed source control management system.
  2. A continuous integration system can automatically run tests on any commit.
  3. Applications can be built and deployed automatically from any commit.
  4. Logs and events from the deployed application are monitored continuously.

A given team or organization may be at different stages of adoption of DevOps and thus may do only one or few of the above. Hopefully, we can all agree that these four items are eventually necessary if we want to claim that all deployments are automated and instantaneous. Since DevOps optimizes for frequent and fast iterations, you can see why it is at odds with security. A security team wants to optimize for fewer incidents and if you try to force security into DevOps you will end up achieving neither.

ON-DEMAND WEBINAR

Crossing the DevOps & Infosec Divide

Featuring Gene Kim, Derek Weeks & Tim Buntel

Even though the DevSecOps movement is in its infancy, there are proven patterns that work and use cases to learn from.

So, Where Does Security Fit into DevOps?

Instead of trying to think about security as something that is a fixed target that you need to aim for, it is better to consider it as a useful property of software that can be gradually improved. If you think this way, you can do a better job of managing risks throughout the Continuous Integration/Continuous Delivery pipeline.

Based on the 4 key elements of DevOps as described above, I would like to suggest the following guidelines that teams can use to improve overall security in a DevOps world.

  • Assess application risk: Even before you start a new project, figure out what risks the application will expose the business to. You do not need to do a full threat modeling exercise (whose benefits are debatable even in SDLC). Simply knowing the kinds of data the application will touch will help plan for better controls later.
  • Require a common baseline security: Do this for all applications, and include things like using CSP, Secure Cookies, TLS only and so on.
  • Enable test driven security: Similar to TDD, write security tests first, let them fail, implement the security control, then verify that the tests passed.
  • Make sure applications are up to date: Developers own the operational security of their application, so empower them to make sure dependencies and libraries are up to date.
  • Manage secrets in code: Alternatively, you can also do this on servers to prevent leaks.
  • Build centralized security services: This frees up others so they don’t have to manage keys and certificates, and so on.
  • Test and audit the underlying infrastructure: For example, make sure you check TLS configuration daily (I cannot stress this enough given the number of times we have had an expired certificate lead to a production incident) for certificate expiry and cipher suites.
  • Incident response plan: Eventually things will go bad; always have an incident response plan and follow it.

You may have noticed I did not use words like scanning, checking and certifying, which are typically associated with application security. I also purposely did not name any tool since I wanted to present a set of generic guidelines.

Towards Continuous Security

If you think about security holistically you will realize that, much like DevOps, it requires a multi-disciplinary approach in order to be successful. Just like we can continuously deliver features over time, we can aim to make our software more robust and secure over time. When you follow this mindset you tend to design systems with security built in. Remember continuous security is just security with DevOps.

This blog was originally published at: http://bit.ly/2uFMDNb. It has been edited slightly for clarity.

For more information on DevOps Security, see the following post by DevOps thought leader and author, Gene Kim:

10 Tips for Integrating Security into DevOps

The post What DevOps Means for Software Security appeared first on XebiaLabs Blog.

Automation is not DevOps

$
0
0

A few years ago, if you would have asked me to define DevOps, my answer would have sounded something like “Mumble mumble automation, mumble, automation, mumble mumble, infrastructure-as-code, mumble mumble, strategery.”

DevOps Automation

Thinking that DevOps equated to automation had mostly to do with the fact that most of the DevOps people I talked to and articles I read really only spoke about automation with only indirect references to anything else.

Implementing automation is definitely a part of what it means to be practicing DevOps, but it’s maybe 5-10%.

The reason that so much of what’s been written about DevOps is focused on automation is that it’s easy to write and talk about tools. Relative to implementing a true DevOps practice, automation is the easy part.

What DevOps actually represents

I’ll use Gartner’s definition to provide a common basis:

DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective. — Gartner.com

Notice that automation is the last thing mentioned. The main components of DevOps are people and process.

This is the hard stuff, the boring stuff, the stuff no one likes talking about because it involves dealing with people and managing work. But it’s also the stuff that gets shit done.

Automation is a force-multiplier, a lever. That’s all computers and software are in general — levers. Without people and process, automation is just a rusted-up socket-wrench— you can use it as a blunt instrument, but you’re not getting its full utility.

Automation alone can have an impact, but mostly in that it allows you to do stuff faster.

Read Starting and Scaling DevOps in the Enterprise Today

In his latest book, “Starting and Scaling DevOps in the Enterprise,” renowned DevOps expert Gary Gruver provides a quick, user-friendly guide that’s a must-read for any large organization needing to understand how to start and succeed with DevOps.

People

At the heart of a successful DevOps practice is a culture that accepts failure, doesn’t focus on blame, and demands collaboration and knowledge sharing.

If your team members are afraid of how their manager reacts when they make a mistake, they will not attempt new ways of doing things and the team and business will not move forward. Full stop.

Screwing up is a necessary part of learning and improving, but most companies have a culture that doesn’t allow even minor failure. I don’t know how many times I’ve heard executives earnestly say “Failure is not an option.” completely missing that they were driving their company into the ground as the industry changed and competitors sprinted past them, having embraced failure as an opportunity to learn and do something new.

Accepting failure doesn’t mean not having high expectations or accepting mediocrity. Accepting failure prevents mediocrity.

The expectation for a DevOps team member should be: “Mistakes happen, don’t try to hide your screw ups. Communicate what happened, work on fixing it, and most of all… learn from it.”

Accepting failure directly feeds into reducing the desire to place blame. Worrying about the repercussions of failure and working to deflect blame take away from doing actual work and fixing the original problem, aside from poisoning the work environment.

When co-workers trust that they’re not going to get thrown under the bus, they collaborate and are more productive. Playing the politics of avoiding and placing blame are distractions that need to be snuffed out. If you’re a manager and you allow your team to sit around pointing fingers at one another, shame on you. If you encourage it (and oh, God have I met those managers), I hope your house gets invaded by bees.

If your goal with implementing DevOps was to speed up delivery and become more agile, you have to aggressively remove roadblocks. Anything that stands in the way of the team collaborating with the business, developers, and each other needs to be bulldozed. Fear, politics, mistrust  –  gone.

It might feel like wrangling a kindergarten class, but you have to get your team to share. There is no such thing as “too busy to train” or “too busy to document”. If only one person knows how to do a thing, they become a bottleneck that can shut down your DevOps factory.

Knowledge sharing has to be the expectation. If there is someone on your team who can’t be coached to not keep things secret, they need to work somewhere else.

Process

You can have amazing automation and culture and still not be practicing DevOps because practicing DevOps is almost entirely about process.

If you want to “do DevOps,” process is where you start and will give you a much higher return on investment than the automation that follows. Without process, there will be too much chaos to maintain a healthy culture, and any tooling you build will likely be solving the wrong problems.

Start by getting visibility into the work your team is being asked to perform. This isn’t just for managers; the entire team needs insight into the work backlog, if for nothing else, than to prevent duplication of work (“I already have a script for that”) and provide time-saving context (“Doing X will cause Y to fail”).

If there are team members who won’t share what they’re working on or only offer vague details, that has to end. Letting people slide by with “I’m working on server things…” during your daily standups (and yes, you should be doing standups), doesn’t fly. “I’m doing X, Y, and Z today” is the answer you’re looking for.

Without that transparency, work goes into a vortex of suck. If work is (or isn’t) being done, the team needs to know, because every unknown status compounds delays, reduces quality, and plants the seeds of distrust. A successful DevOps practice requires accountability, not for the sake of holding someone’s feet to the fire, but just so everyone knows what’s going on and can plan accordingly.

All this requires commitment and continual reinforcement from teammates and management. There is no “We set up a kanban and no one used it so we stopped.” Failure is an option. Not knowing the answer is an option. Working ad-hoc and being lazy about process is NOT an option.

To summarize, if you are not managing work in an Agile way, using Scrum or something similar, you are not practicing DevOps.


It turns out that there are lots of great resources on the non-automation facets of DevOps. Two good places to start are The Phoenix Project and Effective DevOps. The reviews for Effective DevOps are particularly fun because most of the complaints are “the author didn’t talk about automation,” which means she got it right.

The trick when you’re doing research on DevOps is to not search for “DevOps” because you’ll mostly get 1.) articles that are about automation, and 2.) “DevOps” job postings that are really just sysadmin jobs.

Instead, read about Agile and Lean. Read about Personal Kanban. Read things that make you a better person who can treat other humans with empathy. That’s what will make you a “DevOps Ninja.” Focusing entirely on automation just makes you a code monkey.

Editor’s note: This blog was originally posted here.

The post Automation is not DevOps appeared first on XebiaLabs Blog.

GE Power Fleet Services Boosts Deployment Speed and Revenues

$
0
0

The GE Power Fleet Services team develops software to remotely monitor, run diagnostics on, and capture analytics for the industrial Internet solutions they deliver. But their development and production teams had hit a wall in their strive towards continuous improvement. Unplanned work interrupted planned work, software release processes moved too slowly to meet business demands, and painful, disjointed handoffs between teams disrupted the release process.

The team wanted to develop higher quality software faster and improve collaboration between development and production. They began by improving the front end of their software development process with Continuous Integration using Jenkins, but realized they had a lot of software sitting on the shelf waiting to be released. To fully realize the benefits of their move from waterfall to Agile methods, GE Power knew they needed release automation.

Developers Deploy Twice as Fast with XL Deploy

After evaluating IBM, CA, and XebiaLabs, GE Power chose the XebiaLabs Enterprise DevOps Platform to automate their deployments and orchestrate and control their release pipelines. A major factor in their decision was XebiaLabs’ agentless architecture.

The team began by using XL Deploy to automate their deployments. Introducing a new technology into the stack with the infrastructure team was typically a lengthy process. But with XL Deploy’s agentless technology, they could easily deploy their applications with no interruption to the infrastructure team.

Automating their deployments solved GE Power’s initial bottleneck. Their next challenge was to define and improve their pipeline between development, QA, and production.

Getting Control of the Pipeline with XL Release

Early phases of the GE Power pipeline were not representative of the production environment. For example, the configurations were often different, and they often had to abort entire releases, which meant losing critical release metrics.

Using XL Release, GE Power was able to create a controlled pipeline. The team can now define their processes and understand where to automate and how to standardize each stage of the pipeline. XL Release’s metrics and dashboards also allow them to drive continuous improvement, providing metrics that show release failures, identify problems, and offer information to help them solve problems faster.

The Results

Using the XebiaLabs Enterprise DevOps platform, GE Power experienced great results:

  • Releases that took months now take days and only 1/3 of the resources
  • 25 hours per deployment saved, multiplied by hundreds of deployments per year
  • Higher quality software – deployments go into production “first time right”
  • Elimination of rework increased capacity to innovate, which boosted revenue growth
  • Almost 2X return on their XebiaLabs investment this year and expect 5X return next year
  • Critical release data helps team make quick, data-driven decisions and measure success
  • Migration from legacy process to release automation was accelerated due to XebiaLabs’ ease of use

“We automated over 20 packages and found we saved over 25 hours per deployment. One analytic application that took months to get through the pipeline now takes us only days with XebiaLabs. The team is finally deploying into production ‘first time right,’ with no failures.”

Eric Haynes, Director of Architecture and Engineering, GE Power Fleet Services

Check out the full case study here!

The post GE Power Fleet Services Boosts Deployment Speed and Revenues appeared first on XebiaLabs Blog.


XebiaLabs Named A Leader and Highest Ranked for Current Offering by Independent Research Firm

$
0
0

Forrester Wave Leader Badge

XebiaLabs, the recognized leader in enterprise-class DevOps and Continuous Delivery software tools, has been named a Leader in the newly released report, “The Forrester Wave™: Continuous Delivery and Release Automation, Q3 2017,” by Forrester Research, written by Robert Stroud and Chris Gardner. The company received the highest score in the category of Current Offering and in the Product Strategy criterion.

An increasing number of organizations have recognized that Continuous Delivery and Release Automation (CDRA) tools are critical for realizing the full business value of their software delivery cycle. According to the report, “I&O teams must pursue the rapid delivery of applications to provide differentiated customer experiences that meet accelerating business expectations. Faster delivery alone merely leads to customer disappointment when the software delivery process is substandard, deferring to velocity without quality.”

XebiaLabs DevOps Platform for CDRA

“We are very proud to be named a Leader in this year’s Wave report and to receive the highest score in the Current Offering category,” said Derek Langone, CEO of XebiaLabs. “The XebiaLabs DevOps Platform allows the world’s largest companies to scale DevOps across diverse teams and complex environments. We believe that this year’s Wave results validate why our customers have been so successful with our platform. It delivers value for all participants in the software release process and manages the most complex scenarios from code to production. It also integrates seamlessly with existing technology investments, provides unmatched visibility into the software delivery process and can scale to meet the requirements of any organization.”

As a pioneer in Continuous Delivery and DevOps, XebiaLabs provides the industry’s most complete and most scalable solution for Continuous Delivery and Release Automation. Designed for the enterprise, the company’s DevOps platform offers automated application deployment, advanced release delivery orchestration, and DevOps Intelligence. It allows organizations with even the most complex release pipelines to automate and standardize their processes so they can improve software quality while accelerating time to value. In addition, the platform’s Dual-mode capabilities optimize productivity by allowing users to choose their method of work, whether through code or a graphical user interface.

Download the Report

To view and download a complimentary copy of the Forrester Wave Continuous Delivery and Release Automation Q3, 2017 report, visit: https://xebialabs.com/resources/analyst-reports/the-forrester-wave-q3-2017/

 

The post XebiaLabs Named A Leader and Highest Ranked for Current Offering by Independent Research Firm appeared first on XebiaLabs Blog.

KeyBank Gets Deployment Control and Speed with XebiaLabs and OpenShift

$
0
0

“Our DevOps journey began by incident,” said Tom Larrow, DevOps Automation Engineer at KeyBank, one of the largest banks in the U.S., with revenues of 5.8 billion. The “incident,” which Tom described in a recent presentation at the XebiaLabs DevOps Leadership Summit, was a major outage that took their systems down for almost a day. While it made for flashy news headlines, it was, according to Tom, “a major reputational risk.”

KeyBank Logo

But there’s a silver lining. Inside KeyBank, the outage spawned an investigation into their systems, which revealed just how complex they were. One online banking login, for example, required over 190 network hops across two datacenters and a minimum of 6 seconds to get in.

That kind of complexity is a fact of life for a major financial organization, especially one that’s seen much of its growth come from acquisitions. Last year KeyBank acquired First Niagara, which dramatically increased the number of customers using KeyBank’s systems.

“When you acquire companies and plug their systems into yours, you increase the complexity of your system exponentially,” said Tom.

Because of the complexity of their deployments, along with a lack of standard configurations and automation, they could only release software four times per year. Each release was a big deal—all-hands-on-deck, Sunday at 2am, 60 people on a call. It was, according to Tom, like “mission control, with everybody giving a go, no-go for changes.” Because the cycle was so long, they would do things like rush to include new features in the current release or scrap them until the next one.

But a major project was on the horizon: Tom’s team was tasked with building a new online banking platform, which was scheduled for completion by summer of 2017. And when the CEO announced the First Niagara acquisition—and moved the deadline for the new online system up by several months—the pressure was really on. They had to accelerate their process.


EBOOK

The IT Manager’s Guide to Continuous Delivery

Continuous Delivery allows you to get new features and capabilities to market faster and more reliably. This ebook helps managers understand the principles behind Continuous Delivery, explains the transition to a Continuous Delivery organization, and gives practical advice on how to start benefiting from the dramatic improvements Continuous Delivery provides.

Modernizing the Delivery Process

From a platform perspective, KeyBank knew they needed to change how they did business, and that meant modernizing the software delivery process. They began with an overhaul of their old platform, adding Docker containers to build all their online banking components, Kubernetes for container orchestration, and Red Hat OpenShift due to its strong enterprise support and value-added features.

For Continuous Integration, the team installed Jenkins, which they used in conjunction with OpenShift. This approach was great for improving coding, increasing the number and speed of deployments, and fixing issues faster. It was so effective, it allowed them to deliver the new online banking system to their existing customers a year early. The process also helped them meet their deadline for bringing First Niagara users onto their online services, and to rapidly fix any problems with little to no disruption to their millions of new and existing customers. Based on this success, KeyBank wanted to expand their new process to their other applications. “We had to keep improving, Tom said. “That’s the whole point of DevOps.” But spreading the success from the online banking system to their other applications demanded more change.

Reaching the Limits of Jenkins

Tom and his team realized that, while Jenkins worked well for Continuous Integration, it had its limits. Jenkins lacked certain software controls, which led to some problems. For example, there were a few incidents where someone would create an extra job to do testing, and the test code found its way into production.

As a bank in a highly regulated industry, they also saw the need for more mature access and process controls. Maintaining proper segregation of duties and ensuring all aspects of delivery were fully auditable was essential. They knew they needed something more robust—a full enterprise tool. That’s where XebiaLabs came in.

Finding an Enterprise Tool

KeyBank chose XebiaLabs’ XL Deploy and XL Release products to help them get control of their delivery process and scale to include their other applications.

While KeyBank still builds Docker images and pushes them into their registry, they now use XL Deploy to deploy into their lower environments. Before XL Deploy, they were pushing a Docker image that was generically tagged “Dev.” Now, each image includes tags such as a build number and unique identifier. From there, XL Deploy creates a deployment package. The deployment packages are available in XL Release so that the team can select and control exactly which version of code is in any environment at any time. They can also easily roll back to a prior version and capture an audit trail.

By adding XL Deploy and XL Release to their delivery platform, KeyBank has achieved their goal of combining speed and agility with fine-grained control over which software versions go through the pipeline.

To hear KeyBank’s DevOps transformation story firsthand and learn about Tom’s “DevOps Do’s and Don’t’s, visit our DevOps Leadership Summit page or go here.

The post KeyBank Gets Deployment Control and Speed with XebiaLabs and OpenShift appeared first on XebiaLabs Blog.

DevOps at Scale and Compliance too? You Bet!

$
0
0

We frequently hear our customers talk about how much time and effort they spend dealing with compliance issues. And how it gets more and more difficult as they try to deliver software faster to meet business demands. And how it gets even harder at scale.

Fortunately, we’ve built our Application Release Automation tools to make compliance (almost) easy!

  • Need to prove who did what, when and how? No problem!
  • Need to involve risk and compliance teams in the complete software release process? Got it covered!
  • Need the visibility to see what’s going on across tasks, releases and environments, at any time? We can help!
  • Need to proactively mitigate release risk? Sign on up!

But what’s our secret sauce? How do we help companies ‘have their DevOps and prove compliance too’?


XL Release for Compliance

The industry’s top-ranked release orchestration tool, XL Release, automates activities and facilitates manual steps in the release pipeline. Teams have the freedom to model their own release processes and create their own workflows. And everyone — from Dev to Ops to product owners to executive management — has complete visibility into the process.

At the same time, XL Release applies its intelligent risk scoring to actively flag releases that are likely to fail, so you can prevent issues before they become problems. You can also ensure certain steps execute at a certain point in the process, important steps are never skipped, and nothing happens without appropriate approvals. After the release has executed, teams can see a snapshot of the release process along with its contents at the time of the release. The activity log shows everything that happened in a release, sortable by user, action, and a date-time stamp. And with XL Release’s detailed metrics, you can easily spot bottlenecks and see where best to focus improvement efforts.

XL Deploy for Compliance

With XL Deploy, teams get highly scalable, model-based processes to automate their deployments. An environment-agnostic tool, XL Deploy makes it easy to add new platforms and replicate deployments to any environment in a repeatable, standardized, and auditable way. If an environment or application changes, XL Deploy’s model generates a new deployment plan – no need to constantly re-script to meet changing business needs. And rollbacks can happen at the push of a button. Throughout all processes, required steps are enforced and logs are automatically captured so that compliance and audit requirements are easy to meet.

XL Deploy provides a single system of record for deployment events from the minute a deployment is requested until it’s complete – with visibility, control, and proper record keeping across all activities. It’s easy to see exactly which applications are deployed in which environments. Enjoy the benefits of a scalable, zero-touch process that is fully traceable and auditable.

“I wanted to provide a single system of record of what happens from the minute we request a deployment until the minute it is completed – all in a repeatable way with visibility, control, and proper record keeping. With XebiaLabs, we have introduced a highly visible, zero-touch process that is fully traceable and auditable.

“If you’re looking to improve, accelerate, and streamline your end-to-end software delivery, and enforce compliance requirements in a repeatable, auditable process, you want XebiaLabs.”

– Vito Iannuzzelli, Assistant VP of IT, New Jersey Manufacturers Insurance Group

If you haven’t already, sign up now! Try XL Release, try XL Deploy and learn more about XebiaLabs and compliance!

The post DevOps at Scale and Compliance too? You Bet! appeared first on XebiaLabs Blog.

Why DevOps Management is Critical for Software Security

$
0
0

DevOps is not just a hot topic for Development and Operations teams: it brings huge benefits to everyone in the software delivery pipeline—including security. That’s because DevOps, and more specifically DevOps Management tools, helps to prevent security vulnerabilities in the delivery process by bringing order and efficiency to DevOps projects.

As part of a product review of the XebiaLabs DevOps Platform recently published in CSO, writer John Breeden paints a picture of the tension that occurs between Dev and Security, as well as the risks to applications when the delivery process is not well managed:

Organizations that develop and deploy a lot of custom software have learned to deal with issues related to having many programmers touch those products along the way. Programmers have differing skillsets and competencies, people tend to make mistakes, and there is a constant struggle between the developers trying to make the programs work and the security teams who will need to ensure that they are safe once deployed.

The result of all this chaos is that software development is often strung out over months or years, with developers sometimes having to start all over again if a supposedly completed program doesn’t do what it needs to, if it can’t deploy properly into the environment, or if some security flaw is discovered long after the program has been put into production. Further, those security holes are often only discovered after an attacker has exploited them, which can cause huge losses of both data and revenue.

4 Criteria for Improving the Security of Software Delivery

To say you’re just going to “do DevOps” to fix this chaos and risk is too simplistic. According to Breeden, improving the security of your delivery process requires a DevOps management tool that can:

1. Help improve collaboration between Dev and the rest of IT

2. Support a smooth implementation of a DevOps initiative

3. “Perfectly” integrate a large number of tools

4. “Link into any of the environments and operating systems, both physical and cloud, where the programs will eventually reside”

With this criteria in mind, he goes on say that the XebiaLabs DevOps Platform, which includes XL Release and XL Deploy, both of which Breeden tested, “somehow manages to do all that, within almost any environment, and for just about every platform.”

To read John Breeden’s full review of XL Release and XL Deploy, see “How XebiaLabs brings order and efficiency to DevOps projects.”

The post Why DevOps Management is Critical for Software Security appeared first on XebiaLabs Blog.

2-minute Tip: Provision Cloud Environments with XebiaLabs

$
0
0

Perhaps you’ve experienced this pain yourself. As companies shift their operations to the cloud and deploy on a large scale, it can be time-consuming, frustrating, and painful for teams to request the cloud-based environments they need for their application deployments. When provisioning cloud resources is done manually, it slows down the process and doesn’t always provide the level of governance and security required. Not so great for scaling, simplicity, standardization… or sanity!

Automatically provision cloud environments with XL Deploy

So here’s a handy tip: with the XebiaLabs DevOps Platform, you can provision cloud-based infrastructure automatically and on demand … so it becomes an automated, repeatable, auditable part of your deployment process. XL Deploy gives you a single, consistent way of provisioning, no matter what tools you use for virtualized and cloud environments. Build a repeatable process for creating test, QA, pre-production, and production environments as needed. And avoid vendor lock-in too: XL Deploy’s dynamic model will let you migrate smoothly to whatever technology comes next.

Yes, it really is that simple.

Automate your provisioning and deployment process from end to end

Imagine having a self-service portal where your development teams can request the environments they need and have them available for use in a matter of minutes, as a built-in part of the deployment process. Then once you no longer need an environment, it gets automatically torn down. No more worrying that it will take weeks or even months to re-provision it when you need it.

Faster, more automated provisioning through XL Deploy means more efficient use of your cloud environments and less headaches for everyone, from Development to Operations:

  • Automate provisioning and deployment from end-to-end
  • Allocate cloud resources based on usage and security groups
  • Enable teams to get on-demand environments with no wait
  • Automatic tear-down when complete – avoid paying for what you aren’t using
  • Increase efficiency and reduce administrative work
  • Avoid errors: use the same standardized process, every time

Watch this 2-minute video to see for yourself

And then…

The post 2-minute Tip: Provision Cloud Environments with XebiaLabs appeared first on XebiaLabs Blog.

10 Reasons You Can’t Scale DevOps with Configuration Management Tools

$
0
0

Provisioning and Configuration Management Tools

Provisioning and configuration management (CM) tools such as Terraform, AWS CloudFormation, Puppet, Chef, SaltStack, and Ansible are popular choices for infrastructure automation and configuration. These tools effectively manage infrastructure and other components using scripts, which initially seem simple. At scale, however, their scripts are complex and labor intensive, and domain knowledge is often lost as resources transition to other activities.

Application Release Automation (ARA) solutions are designed for a very different purpose: to automate the process of releasing your complete software packages (applications, infrastructure, and configurations) and deploying them to different environments in the enterprise release pipeline, from development to testing to staging to production.

Provisioning environments, orchestrating releases, and deploying applications are all closely related parts of the software delivery process, so you might think that you can use one tool to do it all. Unfortunately, provisioning and configuration management tools alone won’t give you the foundation you need for successful enterprise DevOps at scaleWhy not?

1. They don’t help you orchestrate releases or manage dependencies

The ability to scale effectively requires the flexibility to release at the velocity of the business, whether daily or hundreds or even thousands of times a month. This level of release acceleration requires repeatable release coordination with comprehensive dependency management. Unfortunately, these capabilities are outside the scope and capacity of environment provisioning and management. Delivering at scale requires an ARA solution to orchestrate releases and manage both technical and logical dependencies among applications and microservices.

2. Scripting doesn’t scale

Deploying applications with provisioning or CM tools requires the constant writing and testing of scripts, customizing and configuring them for different applications and environments and updating them every time something changes. This endless custom scripting costs you time and money in the short run and in the long run, and it inevitably leads to quality problems as maintenance continually becomes more complex.

5 Reasons To Stay Away from Workflows - KLP

WHITE PAPER

5 Reasons to Stay Away from Workflows

When it comes to application deployment, “simple ‘n easy” workflows seem quite appealing. However, they suffer from many problems when applied to enterprise deployment automation. Learn why some users choose to use workflows, the drawbacks and why XebiaLabs doesn’t use them.

 

 3. No support for advanced deployment patterns

The larger and more complex your environments are, the more benefit you’ll see from advanced deployment approaches, such as blue-green deployments, canary deployments, and rolling or dark releases. Implementing these patterns with a provisioning or CM tool requires additional scripting efforts, which increases exponentially if you want to support more than one approach. Plus, you’ll face more complicated maintenance in the future.

4. Intelligent and automated rollback is mandatory for success

When a deployment fails, you need a tool that can take action, fast. Provisioning and CM tools don’t offer automated rollback, so when things go wrong it’s nearly impossible to create and maintain custom scripts that will reliably undo advanced deployments. You need a solution that can automatically roll back from a failure that happens at any point in the deployment process.

5. You need visibility into your real-world process

Releasing an application doesn’t just mean provisioning infrastructure and deploying software; most enterprises have business needs that can’t be automated. Provisioning and CM tools don’t account for all of the work that is part of the release pipeline, which means they don’t represent your real-world process.

6. Risk visibility is crucial for all types of stakeholders

The status of a release–and the chance that it’s going to fail–isn’t just a technical concern. Stakeholders across the business need to see release status at a glance and receive proactive alerts when releases are at risk of failing. Provisioning and CM tools are designed to provide status information that’s aimed at technical users and that covers only a subset of the complete delivery pipeline. These tools do not proactively notify stakeholders when there’s a danger that something will go wrong, instead reporting only failure conditions. Why fail when you can avoid it?

7. Reports from provisioning and CM tools simply contain infrastructure data

Of course, provisioning and CM tools collect data in reports that allow you to analyze your processes. This data is inherently limited to the provisioning phase of the pipeline, when what you need are reports that visualize the entire release process and show you where you are in that process. Ideally reports should not just report base data. They should also be based on an individual’s role, providing insight to help individuals and teams improve efficiency and speed by focusing on measurable DevOps goals.

8. Compliance data collection should be a no-brainer

When the tools in your pipeline collect compliance data automatically and present it in an easy-to-read and meaningful manner, meeting compliance requirements and providing information to auditors become easy tasks. Collecting information beyond basic compliance data with a provisioning or CM tool requires you to explicitly identify the data you want, and there’s no guarantee it will be usable for non-technical team members.

9. Access control should be easy to configure

As development teams are empowered to deploy applications as part of their Continuous Delivery process, intuitive user management with granular access control is critical to ensure code that doesn’t belong in Production doesn’t end up there. Provisioning and CM tools require access control to be defined in code, which means that initial setup, consistency across projects, and significant maintenance over time all will be added to the workload of overburdened technical staff.

10. You need standardized processes to scale up

Provisioning and CM tools depend on customized scripts that you have to write and maintain. As a result, using them for application deployment inevitably leads to one-off scripts that don’t scale across the organization, with no release orchestration to help you manage disparate processes. Delivering repeatable, scalable pipelines for releasing and deploying applications allows you to scale your DevOps initiatives, reuse pipelines, and ensure you’re collecting the data you need for compliance and audit purposes.

Application Release Automation brings together all of the steps and tools in your software delivery cycle to accelerate delivery and provide the enterprise-level scalability, reusability, and standardization that your business requires.

Related reading

The post 10 Reasons You Can’t Scale DevOps with Configuration Management Tools appeared first on XebiaLabs Blog.

How Model-based Deployment Accelerates Software Delivery

$
0
0

Scripting deployments doesn’t scale

Adopting Continuous Delivery means finding ways to speed up development cycles and automate software delivery so that DevOps teams can release their applications faster and more reliably. But once you start to scale, some Application Release Automation tools that promise to accelerate software delivery actually slow it down. They require teams to spend time scripting out deployment workflows step-by-step, which results in time-consuming, expensive script maintenance in the future.

XebiaLabs’ deployment model generates flawless deployments… without scripts

The XebiaLabs DevOps Platform is different. It uses a model-based approach that streamlines and standardizes the software delivery process without requiring DevOps teams to write and maintain deployment scripts.

XebiaLabs’ model-based approach means that you only have to specify what you want to deploy and where; the model does the rest, from automatically generating deployment plans to handling rollbacks if something goes wrong. The XebiaLabs model standardizes your deployments so you can scale up to new environments, new target technologies, and new platforms with ease. Perpetual script maintenance becomes a thing of the past, so teams can focus on more productive and fun projects.

Check out this video!

Check out this video to learn about the fundamentals of XebiaLabs’ innovative deployment model and how it helps you achieve fast, automated, repeatable deployments.

 

Learn More about Model-based Deployments with XebiaLabs

The post How Model-based Deployment Accelerates Software Delivery appeared first on XebiaLabs Blog.


Stay Out of the Rain, Episode 1: Meet the unexpected challenges you’ll face when moving to the cloud

$
0
0

“Stay Out of the Rain” is a series of essential insights for migrating applications to the cloud.“Stay Out of the Rain” is a series of essential insights for modern companies looking to release software faster and with higher quality, across ever-changing and complex environments. Written by XebiaLabs Chief Product Officer, former Forrester Research Principal Analyst, and long-time software guru Robert Stroud, this series lays down a clear path of DevOps best practices for moving to the cloud, flags the puddles to avoid, and shares secret shortcuts to get you back on track when the inevitable thunderstorm strikes. Read on and let Rob teach you how to stay out of the rain!

The fact that more and more organizations are moving to cloud-based infrastructure is no secret, but the reality is that cloud adoption is growing even faster than predicted. Organizations in every industry, from finance to manufacturing to healthcare, are embracing the cloud—whether they’re small startups or huge enterprises serving millions of users.

In 2018, Forrester “predicts that more than 50% of global enterprises will rely on at least one public cloud platform to drive digital transformation and delight customers,” (Predictions 2018: Cloud Computing Accelerates Enterprise Transformation Everywhere, 7 November 2017).

And according to Gartner, “as of 2016, approximately 17 percent of the total market revenue for infrastructure, middleware, application and business process services had shifted to cloud … Through 2021, this will increase to approximately 28 percent,” (Gartner Forecasts Worldwide Public Cloud Services Revenue to Reach $260 Billion in 2017, 12 October 2017).

At XebiaLabs, our customers are no different; they’re investing in public, private, and hybrid cloud solutions to reduce infrastructure costs and gain flexibility. And they’re telling us that moving to the cloud isn’t as simple as it sounds in strategy planning meetings. When it’s time to really migrate applications, their teams run into a number of issues that threaten to slow down their cloud initiatives.

1. Managing cloud configurations at scale isn’t always easy

Our experience with organizations that roll out cloud across teams confirms that “moving apps to the cloud” isn’t a one-and-done task. There’s a lot of learning and error-prone setup work that teams have to do by hand: configuring network interfaces, public IP addresses, network security groups, virtual networks, security rules, subnets, route tables… and potentially more. Plus, the implementation details are different for every cloud platform. Teams lose time tweaking, troubleshooting, managing, and maintaining configurations across applications and environments. They’d rather be coding!

2. Cloud services aren’t as fully integrated as you might expect!

Most teams dive straight into the setup that’s actually needed to run their applications. They then discover that configuring the cloud environment to support them is so complex that getting an application up and running means consuming 10 or 20 different cloud services that aren’t always fully integrated with one another. Weaving a working application out of the tangled web of cloud services and ensuring that those services work together properly costs teams even more time and makes migrating each new application to the cloud as painful as the last.

3. Cloud costs explode to consume all available budget and more

The promise of access to pay-as-you-go infrastructure is appealing; that said, it’s hard to predict the resources and bandwidth that you’ll need in the future. So, pay-as-you-go plans might save or might cost you more money than you envisaged. This makes it hard to price-compare between cloud providers, and it means that costs can add up faster than teams realize if they’re not closely monitoring their cloud usage and taking action when it exceeds their budgets.

WHITE PAPER

Enterprise Software Delivery in the Age of Containers

How can enterprises take advantage of the benefits of container technology without creating more work for their teams? Download this free whitepaper to learn where containers fall short and how Release Orchestration and Deployment Automation tools can bridge the gap between the promise of containers and the realities of complex enterprise application delivery.

4. Lock-in remains a trap

The cloud landscape is constantly changing as providers roll out new platforms and services. Our customers want to be sure they have the flexibility to move between vendors so that they can take advantage of cost savings and new cloud products. But making release and deployment processes truly cloud-agnostic is an ongoing technical challenge. Teams that successfully lift and shift applications from on-premises infrastructure to the cloud might find that they’re not much better off in the cloud because they’re locked in to a particular platform or provider.

5. Security cannot be an afterthought

Cloud providers should be congratulated for elevating encryption as a vital security measure, but our customers are realizing that there’s more to consider if they want to ensure applications are fully secure. Many organizations assume that the cloud provider will take care of security so that it’s “just there”; but some have learned the hard way that insufficient security exposes them to extreme risk.

Cloud-based environments and the applications that run on them have to be hardened against potential data breaches and hackers that abuse cloud services. Running applications in the cloud makes it more important than ever to bake secure development practices and compliance checks into the release and deployment process.

“Stay Out of the Rain” is a series of essential insights for migrating applications to the cloud.Transition to the cloud while staying dry with ARA

The good news is that the right Application Release Automation (ARA) solution will keep the cloud from raining on your DevOps parade.

ARA helps organizations efficiently manage and optimize release pipelines by providing control over the release process and by integrating the tools in the software delivery cycle. With ARA, you can accelerate delivery while getting enterprise-level scalability, reusability, and standardization, so you can optimize the benefits that cloud-based infrastructure has to offer.

Managing complexity at scale

Migrating applications to the cloud doesn’t automatically eliminate the complexity of releasing, deploying, and running them at enterprise scale. ARA provides a foundation that helps you manage complex cloud environments by centralizing configuration data, reducing duplicate work and promoting reuse of the right cloud configurations. An ARA solution also empowers you to enforce security requirements even as your application landscape gets more complex, by standardizing on release processes that have security and compliance checks built in.

When you can map and abstract cloud configurations that are vetted and secure, you can immediately deploy the same applications on a variety of clouds like AWS, Azure, and Google, and avoid vendor lock-in.

Any cloud, any time

Avoiding vendor lock-in and achieving cloud independence isn’t just about centralizing cloud configuration data; you also need a way to decouple applications from infrastructure. An ARA solution that automatically models deployments makes your applications portable. You can take workloads that are already running on-premises and deploy them anywhere—whether that’s on a public, private, or hybrid cloud—and you gain the flexibility to move them as your cloud choices evolve and change.

Predictability of cloud costs

To stay on top of cloud expenses, you have to know what’s running where. Real-time status information is a must for monitoring your cloud usage, and historic reporting across your complete software delivery pipeline can help you investigate overages. You can give development teams the power to spin up cloud instances quickly and easily as part of their release pipelines, while still controlling cloud usage and saving money by automatically de-provisioning instances that are no longer in use.

The XebiaLabs DevOps Platform: Your umbrella in the rain

Recognized by top industry analysts as a leading Application Release Automation solution, the XebiaLabs DevOps Platform solves the unique challenges of scaling cloud usage in the enterprise:

  • Manages hundreds of cloud environments by centralizing configuration data, including secure cloud configurations
  • Achieves cloud independence for your applications, so you can move to any public, private, or hybrid cloud platform without writing new deployment scripts
  • Monitors cloud usage and automates the management of cloud-based environments

Related reading

The post Stay Out of the Rain, Episode 1: Meet the unexpected challenges you’ll face when moving to the cloud appeared first on XebiaLabs Blog.

DevOps Transformation Story: Paychex

$
0
0

We recently had the pleasure of sitting down with Matt Cipollone, Enterprise Build Automation Manager at Paychex, to discuss the highlights of their DevOps transformation story and how the XebiaLabs DevOps Platform helped them succeed.

As a large provider of payroll, human resources, and benefits outsourcing services, Paychex has seen continued growth and is now approaching $3 billion in revenue. Matt and his team kicked off their enterprise DevOps strategy with the goal of creating a high-volume, high-demand software delivery model. The focus: improving both their software delivery velocity and output quality of their releases. Challenged by disparate processes and traditional waterfall methodologies, the Paychex team needed a solution that would provide consistency across different environments and approaches.

Matt detailed how XebiaLabs helped Paychex through their DevOps transformation. “Since we brought in XebiaLabs in, we have achieved consistent deployment and release processes and have really gained good visibility into the bottlenecks and into the processes,” explained Matt.

By adopting the XebiaLabs DevOps Platform, Paychex has:

  • Increased the number of total software deployments by 656%
  • Decreased the number of release rollbacks by 36%
  • Reduced deployment time 50 percent

Paychex can now deploy and release more frequently, more consistently, and with fewer errors. With XebiaLabs, Matt and his team have a standardized yet customizable approach to attain repeatable, highly visible, and auditable results. For Paychex, XebiaLabs has proved to be above and beyond the most mature and capable DevOps solution. Matt closed with, “XebiaLabs really gives us the consistency we need to meet our business objectives today and tomorrow.”

View the full interview here:

Read more about Paychex’s story and success they’ve achieved with the XebiaLabs DevOps Platform here.

Related reading

The post DevOps Transformation Story: Paychex appeared first on XebiaLabs Blog.

Vote for Your Favorite Tools to Make It into the Periodic Table of DevOps!

$
0
0

The temperature is finally starting to climb as summer approaches, and things are only going to heat up with the NEW version of the XebiaLabs Periodic Table of DevOps Tools coming summer 2018. To turn the heat up even more, we’re asking you to vote for your favorite tools!

DevOps Hot or Not Tool - Vote now to get your tool into the next version of the XebiaLabs Periodic Table of DevOps

Use Our DevOps Hot or Not Tool to Vote

Any votes cast using our DevOps Hot or Not tool will be considered for a final spot on the new Periodic Table of DevOps Tools, version 3.

Qualified voting began on May 1st and will end at 11:59pm ET on Tuesday, May 15th.

What tool is hotter in Configuration Management, Containerization, Continuous Integration, and more? The power – and the vote –  is in your hands! While voting, click “Access the stats” to see how many votes have been cast in total and by matchup. Be sure to use the “Share This Matchup” feature on the “Hot or Not” platform to either email or share with your social networks, extending the voting to friends and colleagues.

So, what are you waiting for?! Grab a seat and a snack, and get voting now!

Vote for Your Favorite Tools to Make It into the Periodic Table of DevOps!

The post Vote for Your Favorite Tools to Make It into the Periodic Table of DevOps! appeared first on XebiaLabs Blog.

XebiaLabs Now Certified as a SUSE Ready Solution for the SUSE CaaS Platform

$
0
0

SUSE CaaS Platform

Greetings from Copenhagen, where the KubeCon Europe conference recently came to a close. It was great to be at the show, hearing insights from top thought leaders in the open source and cloud native computing field.

I’m excited to share that, during the conference, SUSE, a pioneer in open source software, announced that XebiaLabs is now a “SUSE Ready” solution for the SUSE CaaS Platform. Customers can find XebiaLabs listed in the SUSE Partner Software Catalog, the primary source for customers looking for supported solutions to run with SUSE software.

Our partnership with SUSE is part of our expanding support for containers and platforms that use the open source docker container format.

The XebiaLabs DevOps Platform orchestrates containers as part of the complete application delivery pipeline, from code checkout to running in live production and everything in between, including deployments to container and other environments, manual tasks and approvals, and promotion of releases across stages, from test to staging to production.

To learn more about how enterprises can take advantage of the benefits of container technology without creating more work for their teams, click on the title below to download a free white paper:

Enterprise Software Delivery in the Age of Containers

Containers can help simplify and create more agile software delivery environments. But retaining this efficiency becomes difficult as deployments stretch across multiple applications and environments. Download this free whitepaper to learn where containers fall short and how Release Orchestration and Deployment Automation tools can bridge the gap between the promise of containers and the realities of complex enterprise application delivery.

Related Resources

The post XebiaLabs Now Certified as a SUSE Ready Solution for the SUSE CaaS Platform appeared first on XebiaLabs Blog.

Bridging the Gap: Leveraging Containers for Large-Scale DevOps

$
0
0

Containers are a great technology for improving certain software delivery processes. However, the typical challenges that come with large-scale enterprise software releases don’t simply disappear by implementing containers.

In fact, containers can introduce a variety of complexities and dependencies that ultimately make it more difficult to scale software delivery in an enterprise environment.

DevOps, Containers

In large organizations that want to quickly and securely deliver high-quality software using containers – and scale their efforts to hundreds or thousand of deployments – DevOps teams cannot overlook certain critical management needs:

  • A standardized, repeatable way to deploy software across the varied environments of enterprise IT infrastructure
  • The ability to manage multiple interdependent services and complex processes
  • The enforcement of core enterprise requirements, such as compliance, security, reporting, audit trails, and process controls
  • Real-time visibility into all application components, release processes, deployment artifacts, and release status

The Enterprise Challenge

Container management tools, such as Kubernetes, Docker, OpenShift, and Google Kubernetes Engine, allow developers to bundle all of the components of an application into a single package. By packaging everything an application needs to run – code, runtime, system tools, and system libraries – into a self-contained unit, DevOps teams can drastically simplify deployment to test, user acceptance, and production environments.

While this approach is ideal for deploying one-off applications to a single environment, things can get pretty complicated when you’re looking at using containers in a release pipeline that has hundreds of applications, a diverse IT infrastructure, and a variety of demanding compliance requirements.

In addition, no large organization works exclusively with containers, and therefore, scaling software delivery efforts will require applications and their myriad dependencies to be managed and orchestrated across hybrid environments, not just containers.

For enterprise DevOps deployments, it quickly becomes apparent that containers are not a complete solution.

Enterprise Software Delivery in the Age of Containers

WHITE PAPER

Enterprise Software Delivery in the Age of Containers

How can enterprises take advantage of the benefits of container technology without creating more work for their teams?

Check out this free whitepaper to learn where containers fall short and how Release Orchestration and Deployment Automation tools can bridge the gap between the promise of containers and the realities of complex enterprise application delivery.

The Key to Containers

It’s nearly impossible to scale complex container scenarios without tools to help orchestrate releases and automate deployments across the entire software delivery pipeline.

Leveraging an Application Release Automation (ARA) tool with Release Orchestration and Deployment Automation capabilities can play a vital role in bridging the gap between the promise of containers and the realities of complex application delivery.

Select a tool that provides the key functions IT teams need to complement container use in enterprise environments, including:

  • Creating consistency by centralizing configuration for all container formats
  • Eliminating scripting by instead modeling deployments and creating reusable release templates
  • Ensuring compliance and security procedures are baked into the release
  • Accounting for both technical and organizational parts of the delivery pipeline
  • Orchestrating the release pipeline from end to end
  • Managing complex releases, dependencies, and microservices
  • Simplifying migration to new platforms by standardizing release and deployment processes and configurations

Containers can improve software delivery and scale in enterprise environments if they are well managed and implemented with the previously mentioned requirements in mind.

For more info, read our latest white paper.

Related Resources

The post Bridging the Gap: Leveraging Containers for Large-Scale DevOps appeared first on XebiaLabs Blog.

Viewing all 59 articles
Browse latest View live