devopsy.kinsta.cloud

Category: DevOps Practice

IBM Acquires Red Hat to Create DevOps Behemoth

In a move that has massive implications for DevOps teams across the enterprise, IBM today announced it is acquiring Red Hat in a deal valued at $34 billion.

Red Hat will join IBM’s Hybrid Cloud group as a distinct independent unit. Red Hat will continue to be led by Jim Whitehurst and Red Hat’s current management team. Whitehurst will join IBM’s senior management team and report to IBM CEO Ginni Rometty. IBM intends to maintain Red Hat’s headquarters, facilities, brands and services practices.

IBM expects to close the deal, which will be financed using both cash and debt, in the latter half of 2019. IBM also said the deal will be accretive within 12 months after close, as the combined entity moves to address a total market that spans application development and deployment, IT services and security and collectively exceeds $1 trillion, or more than one-fifth of the total global IT market valued at $3.7 trillion in 2018 by Gartner.

IBM and Red Hat have had a partnership in place for 20 years, spanning everything from reselling and supporting Red Hat Enterprise Linux (RHEL) to collaboratively working on open source projects such as Kubernetes.

IBM officials said they expect Red Hat to significantly bolster IBM’s hybrid cloud business, which already generates $19 billion a year in revenues. IBM noted that about 80 percent of application workloads have yet to move to the cloud.

The move to acquire Red Hat comes on the heels of Red Hat acquiring CoreOS, which augments the company’s existing open source expertise with a container management platform built on top of Kubernetes.

Once the deal is closed, IBM said the two companies will remain committed to open source software licensing, including initiatives such as Patent Promise, GPL Cooperation Commitment, the Open Invention Network and the LOT Network.

IBM and Red Hat also plan to continue to build and enhance existing Red Hat partnerships, including those with major cloud providers Amazon Web Services, Microsoft Azure, Google Cloud, Alibaba and others that compete directly with IBM Cloud.

It’s too early to say to what degree those cloud service providers will be open to continuing to work with Red Hat as unit of IBM. In recent months Red Hat increasingly has been positioning itself head to head against VMware, which operates as a unit of Dell Technologies. IBM also has a strong relationship with VMware that could change in the years ahead. What is clear, however, is that any deal of this magnitude usually begets others in very short order.

— Mike Vizard

October 28, 2018
Integrating the Database into DevOps for Business Success
The benefits of DevOps have been known for some time, but this year’s “Accelerate: State of DevOps” report shows that successful companies are extending the advantages they get from adopting it. The longest-running research of its kind, the report from DevOps Research and Assessment (DORA) represents five years of work surveying more than 30,000 technical professionals worldwide.

Based on their input, the report previously split organizations into low, medium and high performers. This year it added a new category—elite performers—who are embracing DevOps to raise the bar when it comes to the benefits they gain. Elite organizations are able to deploy code 46 times more frequently than low performers, lower lead times from committing to deploying changes to less than one hour (compared to one to six months in low performers), and recover from incidents 2,604 times faster.

The Importance of the Database

For the first time the report also focuses on the vital importance of the database to successful DevOps, echoing research from Redgate. As it points out, deploying changes to the database is often a bottleneck, slowing down DevOps. To overcome this, the Accelerate report recommends integrating database work into the software delivery process, based around four good practices:

Strong Communication and Cross-Team Collaboration

Traditionally, the teams involved in application and database development have had different priorities and responsibilities. The biggest concern with the database was to limit change to keep data safe, while application development was all about creating features, often without regard to what impact they would have on the database.

With DevOps, this has changed. The faster releases of smaller changes it encourages means the database cannot be a logjam at the end of the development pipeline. Instead, it needs to be part of the same workflow, so good, ongoing communication is vital.

In many organizations this is already happening: Fifty-eight percent of respondents in Redgate’s 2018 “State of Database DevOps” survey said that collaboration between developers and database administrators (DBAs) was either good or great, showing that the processes and teamwork are in place to break down any walls between departments.

Comprehensive Configuration Management

Using configuration management tools for software development is a central part of achieving successful DevOps results. To avoid issues, these same practices and tools need to be extended to cover the database as well. Handling changes systematically creates a seamless flow that enables faster releases and dramatically reduces issues—vital when more than a third of respondents to Redgate said they deployed database changes either daily or more than once a week.

Extending Version Control to the Database

As part of taking a holistic view, the Accelerate report found that extending version control from application code to database code delivered major benefits. Elite and high performers store database changes as scripts in version control and manage these changes in the same way as application changes. This is a task that is shared between DBAs and developers—75 percent of respondents to the Redgate survey said that application developers now build database deployment scripts, and were responsible for deploying these database changes to production in nearly half (47 percent) of organizations.

Building a Strong Culture

Culture is a strong factor in whether DevOps succeeds or fails in an organization. This is unsurprising given that DevOps is a very different process to those it replaces, focusing on speed, collaboration between teams and a willingness to be open and continually learn and improve.

Most people are now familiar with the work of sociologist Ron Westrum, who characterized the culture within organizations as one of three types:
- Pathological (power-oriented) companies work in silos, don’t cooperate and are quick to apportion blame if something goes wrong.
- Bureaucratic (rule-oriented) companies are more open, but are still suspicious of novelty and tolerate limited co-operation between teams.
- Generative organizations are most suited to successful DevOps, with a focus on co-operation, surfacing problems, breaking down silos, holding postmortems to understand why things have not gone well and continually experimenting to drive improvement.
To create the right culture for DevOps, leaders need to build trust with their teams, empower them with autonomy and rely on strong communication to ensure that everyone understands their role and overall objectives.

Summary

The latest “Accelerate: State of DevOps” report has a simple, top-line message: Higher software delivery performance enables better business outcomes. Achieving this requires taking a development-wide approach to DevOps, incorporating the database seamlessly into DevOps flows, communicating and collaborating between teams, sharing technical practices, and building a strong, open culture across organizations. Only then can businesses become high or elite performers, with an agile infrastructure that underpins their success.

— Matt Hilbert
October 26, 2018
DevOps: Making Developer Experience Reality
As DevOps professionals, among other things we are responsible for making developers’ lives a little bit easier. How many times have you heard, “Do you have a working vagrant box?” Or maybe you need to set aside a few days to onboard a new developer.

Many times a development environment is created when a project is started, usually on a developer workstation. This typically means it will work on that laptop. But, as the project evolves and more engineers get involved, the need to share this environment becomes apparent. When the project grows in complexity, requiring more components and third-party services, this organically grown developer environment quickly becomes unmanageable.

Get Ready for Production

Another interesting aspect of the developer environment is the level of similarity with the actual production environment. Even evaluating this aspect requires that you have insight in what production looks like. If projects start on a developer laptop, the desired production setup is seldom considered. More times than I care to remember, I was called into a project when the “thing” that worked well on the development teams’ laptop had no sensible production deployment format.

This teaches us that even if we start out small, we must think about how the project will function in a production environment and how we are going to get it there. In practice this means that any new project requires at least the following:
- Some unit tests, they may even start out as stubs.
- A minimal deployment target environment.
- Continuous integration (CI), running the (stubbed) unit tests.
- Automated delivery, preferably continuous deployment (CD).
- At least one simple integration test, possibly just a curl to the deployment app to verify it is alive.
This does add some complexity to your project startup, possibly beyond an individual developers’ abilities. It does, however, lay the foundation to, at the very least, be able to deploy the application somewhere. For a seasoned DevOps professional, adding a basic CI/CD only takes an hour or so and there are plenty of free cloud resources for small projects.

When the project grows and the development environment gets more complex, things get a bit more tricky. The above steps will not really help you mitigate the possible frustration of keeping all the moving part inline. A pattern I see often is that developers try to spin up the entire production stack on their laptop. For a containerized environment, this might mean a Docker Compose-based setup or even minikube to run a local kubernetes cluster. These tools often are using shared volumes for quick iteration, which work well until a large number of files need to be kept in sync. Vagrant is a great way to quickly spin up an environment. This does offer some level of production parity, but certain parts are missing: The CI/CD system watching commits to your source code repository is not deploying to your local setup and traffic to and from it are not passing any additional infrastructure such as load balancers or firewalls, to name a few.

Local-Remote

When things break in production, “It it works on my laptop!” is a phrase we have all heard at some time or other. What if we could bring the laptop environment a bit closer to production? It’s not the developers’ fault if things break in production but work well on the local workstation. Providing an option for developers to develop iteratively using a remote infrastructure means we can get closer to production parity. Also, it means that onboarding new developers in the team could be simplified significantly because all the complexity is in the remote environment. This remote environment is provisioned in the same automated way as production, so we have a great degree of confidence about its state. For Kubernetes-based environments, many great tools exist including Skaffold and Draft. They both provide an easy way to build, push and deploy applications to a Kubernetes cluster. This makes it easy for the developer to take on the responsibility to ensure the application under development will run in the target environment.

If, for some vague reason, you are not containerizing you applications but run code in a virtual machine instead, there are also options. Most modern editors provide automatic syncing with a remote server, either on-demand or when code is changed. Ksync is a tool for syncing your local code into a pod in a Kubernetes cluster on file change. Syncing code live removes the delay of rebuilding a container image and uploading it every time you want to see it in the deployment environment. As such, code sync tools are better suited for iterative development.

Recently, I worked with a client setting up Telepresence for a development team. This is also a tool for Kubernetes environments but it offers a twist—developers get to run their code locally with all traffic in and out proxied through a remote Kubernetes cluster. Like with sync tools, this means there is no more long delay before viewing changes, IDE debugging works as normal and all the log output is local as well. When code is committed and pushed, the CI/CD system should update the cluster with the latest version, which in turn can be used to iteratively develop on with Telepresence. It’s a relatively young project but offers great potential. An added advantage is that only a small portion of the entire application stack or landscape needs to run on the developers’ laptop, which means it can do with less memory and a cheaper CPU.

Conclusion

Containers and microservices are more widespread than ever, making it increasingly difficult for developers to have a production-like environment to develop in. The key to solving this problem is to not try to load everything into an evermore powerful laptop, but splitting the load and complexity between developer workstation and a remote environment.

— Alex Knol
October 26, 2018
How GitOps Can (Sometimes) Save DevOps

A lot has been written about GitOps since its release by Weaveworks more than a year ago as a “single source of truth for the whole system” for using Git for Kubernetes deployments on the cloud.

Aptly described by Alexis Richardson, Weaveworks co-founder and CEO, as “90% best practices and 10% cool new stuff,” GitOps largely offers a framework for DevOps CI/CD deployments on Kubernetes. This was something very often seen as missing among the many Kubernetes management distributions on offer—hence, its popularity.

The tool is obviously not of use for organizations that have not adopted Kubernetes, but in many ways has enabled organizations’ DevOps to more efficiently take advantage of Kubernetes by running Git in a more disciplined and focused way.

“The idea behind GitOps is to maximize the time developers spend on productive coding versus worrying about working with the latest source code, merging their saved code back into the repository and continuously supporting problems that come up during the application build process,” Torsten Volk, an analyst for Enterprise Management Associations (EMA), said.

GitOps offers DevOps a way to use its version control capabilities to archive changes to application deployments in a way that allows them to be recalled at a later time. This can come in handy when an architecture fails and it is necessary to access and reinstate a previous version of an application deployment or update prior to the incident. All changes are tagged and archived in a way that each developer knows when and how their changes to an application were changed.

“Ideally, each developer would check in their code and receive a link to the running application with his or her latest changes applied, as well as with all the other changes that were checked into the repository,” Volk said.

The Adoption Checklist

Volk offered the following elements he said DevOps should have in place before adopting GitOps:

— All infrastructure and application configurations, including databases, middleware and machine learning models, need to be defined as code, Volk said.

“Everyone must accept the basic concept that code is only complete when all components for a successful build are checked into Git,” he said. “CLI-driven, ad hoc deployments are no longer acceptable.”

— The DevOps group has to be able to detect changes to application code that previously might have been able to bypass Git. There must be thus be a process in place to bring these changes back under GitOps control, Volk said.

“The IT Ops/DevOps teams need to make operational changes to the app exclusively via changes to the code checked into Git,” he said. “This means that tasks such as scaling, failover, creating maintenance windows, etc. as well as urgent troubleshooting tasks have to run through Git. The latter is especially tricky, as the enterprise will not accept longer mean time to detect (MTTD) and mean time to repair (MTTR) due to GitOps.”

— Declarative management practices have to be used in Dev and Ops. “This has proven to be a critical roadblock,” Volk said. “Kubernetes developers, as part of Dev and Ops, still often prefer the control of imperative management over the promise of defining their desired end state and letting the software deal with how to get there.”

For DevOps teams that have the prerequisites in place as described above to use Git to run Kubernetes deployments on the cloud, then GitOps deserves at least a look. However, for those organizations that adopt GitOps for the right reasons, it is not designed as a one-size-fits-all solution and organizations will need to modify it to fit their needs. Its implementation, for example, will almost certainly different compared to how Weaveworks described its functioning after using it for two years to run Kubernetes and Prometheus telemetry databases on a cloud platform.

DevOps will, thus, need to be actively involved in GitOps deployment and maintenance to make sure it meets organizations’ individualized needs. When first describing GitOps, Weaveworks’ Richardson wrote: “Fair warning: this is what works for us, and dear reader, you may disagree.”

— B. Cameron Gain

October 23, 2018
You’re Thinking Software Wrong
Like any industry, DevOps fosters its own unique culture. And like any culture it resists change, it has inertia. “This is how it has always been done” is an incredible force to reckon with.

Even though the realities of DevOps have changed dramatically in recent years with the advent of new tools and services, many ideas that have been ingrained in the culture will probably still be with us for ages. Some of these ideas are not only wrong, they border on being dangerous. One such fallacy is the sacred rule cherished by development teams and system administrators: “NEVER deploy on a Friday afternoon.” That is, unless you want to spend your entire weekend fixing bugs. A more pernicious example is the division of labor between us, humans with “root access” to machines, and the robots, the tools teams create to make their processes less manual. These days you’ll still find many development groups that delegate the menial tasks to automation, but keep the most dangerous, infrequent tasks to human operators. These are two prime examples of “thinking software wrong.”

These ideas are not only incorrect, they can be crippling to an organization, causing delays in software development and leaving the company vulnerable to data breaches, for no good reason. These fallacies are what we refer to as “broken culture”—what happens when culture is deeply misaligned with the interests of the organization, the individuals who compose it and its stakeholders. It usually manifests when historic cultural norms prevent members from embracing new and better ways of doing things.

Fear of Friday deployments is our first example of broken culture. This idea has taken a strong hold in DevOps culture because developers haven’t trusted their own software and systems enough, and they don’t want to spend their Friday nights (or the whole weekend) debugging a production problem. Fair enough, but there is a better way.

Let’s look at another example: the Equifax breach. This incident—which cost the company billions of dollars and continues to haunt consumers to this day—happened because a certain procedure mandated that a specific piece of software must always be updated by a human. Since humans are prone to error, this lone simple procedure (designed and supported by years of a broken DevOps culture) resulted in a devastating data breach. Once again, there is a better way.

Deploying is not the same activity it was a decade ago. Advanced automation tools are drastically streamlining deployments, significantly reducing the chance of error and speeding the time it takes to identify and correct any errors that do occur. This means companies can deploy any day of the week and any time of the day, worry free—and can let the deployment date be dictated by what is best for the company and its customers, not the weekend plans of developers.

The same concept applies when it comes to updating software. A better way is to leverage the automation tools that are now readily available, and allow organizations to have robust management of compliance requirements without human error or delay.

In addition to embracing better tools, here are a few other ways companies and developers can rethink software for the better:
- Software must be valued as more than just the cost it takes to create it, or to replace it. Code should be an asset, not a liability.
- Software should be thought of as constantly changing—a dynamic system with which people, machines and processes interact continuously. When this never-ending process is supported by the right tools, deployments are easier and managing and updating software is seamless and secure.
- Code by itself is useless. It needs infrastructure to build it, and data to create something meaningful. Therefore, if you only test the code, but are not managing your infrastructure in the same way, you’re not really testing the software system.
- Companies can dictate the cadence at which they create new software, but they do not have this same luxury when it comes to fixing broken software. Identifying and fixing problems must be done as soon as possible.
- Every new update or fix must be version controlled so that everything is auditable. That includes changes to infrastructure configurations!
Once companies truly understand these fundamental truths about software and embrace the modern tools available to them, they can start to shed the aspects of DevOps culture that are limiting or damaging.

Companies can deploy new apps and features on Fridays, confidently and without issue. Companies can even rebuild an entire infrastructure from scratch, in minutes, while applying all security updates for every single service and library—and be completely sure nothing will break. If you can’t do that—or don’t believe you can—you’re thinking software wrong.

— Ori Pekelman
October 18, 2018
Integrating DevOps: Avoid These Common Mistakes

DevOps, as the name implies, is a combination of two professional teams—software development and the IT experts. Both the teams collaborate well with the aim of creating a bridge that accelerates and automates the process of software development and a more intensive testing before releasing it into the market with high confidence.

DevOps has been identified as a software engineering culture that relies on philosophies and practices to bring more agility and improve the organization’s efficiency to cater continuous delivery and integration.

Now, with the introduction of DevOps culture and transforming trends, the development and operations teams no longer work in isolation. In fact, the role of the DevOps team is also to keep an eye on the software development and manage the infrastructure.

Many organizations have already begun using the DevOps, while various others are on their way to implement the new software development trend. According to a survey, the number of software developers adopting DevOps has increased to 17 percent in 2018 from 10 percent in 2017 worldwide.

It is a good decision to implement DevOps and maximize its benefits to the fullest. However, choosing the right tool can be difficult, which could lead to mistakes and further lead to project delay or a complete failure. To avoid this situation, here are some of the common mistakes DevOps developers usually commit while undertaking the projects.

Choosing the Wrong Team to do the Job

One of the major mistakes organizations make while integrating DevOps is choosing the wrong team to do the job. It is the task of a proficient project manager to choose an appropriate team, but when inexperienced people come on the board, there can be issues.

DevOps is a blend of both development and operations; thus, it’s a complicated job. DevOps is not limited to just bringing agility but also conducting the right deployment. Also, developers have to focus on both ends—development and administration—equally.

Problems can occur when you start concentrating on one aspect of the cycle. So, it is better to hire an experienced team on both ends that can work in full coordination and collaboration with one other. Thes should have a sound technical knowledge and expertise in bringing the best.

Starting a DevOps Project Without Planning

Before commencing any project with DevOps, you first need a foolproof strategy and extensive planning. All of the members involved in the project need to understand their role comprehensibly.

However, some organizations don’t think much about the planning and preparing a road map. They are just anxious to work on the project to complete it as soon as possible.

This is a wrong mindset that will never be successful. Maintaining a good speed and delivering the project on time is perfect practice, but you cannot prefer speed over quality.

Emphasizing More on the Agility

Some of the DevOps developers have a misconceptions that Agile development alone will create a win-win situation for them and that they will deliver optimum applications. But the truth is the other way round.

Yes, you cannot deny the significance of agility in DevOps development, as it has changed a lot from waterfall. However, merely depending on it to implement DevOps is not the right approach. When you use Agile, you primarily work on incremental, iterative work cadences. It is focused more on ensuring the customer satisfaction but you cannot deliver quality product, as Agile doesn’t have the proper infrastructure.

Getting Rigid During the Implementation

Don’t try to be too rigid while integrating the DevOps. This can hamper the entire project; it is difficult to act in accordance with the core tenets of DevOps. However, you can make adjustments using the DevOps model.

You also should lay some guidelines about how to manage the stability of DevOps in the beginning and make sure it remains the same, even if problems occur.

You won’t always get the desired result, so be prepared for any unexpected outcomes. You need to identify the root cause of the issue and so make adjustments accordingly within the DevOps ecosystem.

Not Complete Buy-in

Your DevOps implementation can also fail if both the development and the IT team are not fully on board. Therefore, it’s crucial that every professional involved in the project is synchronized.

Remember, if you get stuck at even one point during the development or the testing, it would delay your project. Coordination should be well-knit and there should be one experienced person who can manage the entire team.

Not Conducting Tests at Regular Intervals

Another mistake during DevOps implementation is not running tests at regular intervals, which will provide improved outcome. You need to run the tests synchronously.

Executing the tests at the same time will save lot of time and will allow you to complete your project within set deadlines. You need to employ the concept of continuous integration and continuous deployment (CI/CD) for the automatic process of test cases.

Don’t Take Security for Granted

While incorporating the DevOps, you are making a big mistake if you take security for granted. The two complement each other, and so security cannot be ignored. You have to plan a strategy for strengthening the security right from the beginning so that you don’t face any problems later on.

For instance, if you expand the architecture using DevOps and afterwards find that security is not updated, you will have trouble. If you are developing a microservices architecture, security will come into play as apps interact with one another. And keep in mind that at no point of time can you compromise with security to provide ease of access.

Not Giving Importance to Database

Often developers avoid the importance of database during the integration of DevOps—while the implemention expands, the database falls short due to the automation process.

The automation of database is also necessary as part of other issues such as managing the codes and continuous integration. You have to deal with the database carefully, as it plays vital role for the data-related apps.

Implementing New Technologies Earlier

It is good practice to choose the latest technologies for a project but when you are implementing DevOps, you need to be cautious. It is recommended not to jump on new techniques straightaway without proper knowledge and research—don’t go for the experiment.

Don’t be a copycat and use any procedure just because others are using it. Plugins change frequently. You need to use tools smartly and intelligently according to the project requirements. Analyze the pros and cons of each of the use cases and then make a proper decision.

Conclusion

DevOps is a good software development and cultural practice that has gained enough attention round the world. It advocates automation and keeps a check on the entire cycle of software engineering, bringing both the development and the IT team in union.

However, the developers commit mistakes while implementing the DevOps and so it’s important that they should be aware about these in advance.

— Mehul Rajput

October 16, 2018
Implementing ChatOps Using Open Source Tooling
ChatOps is an exciting proposition for organizational Ops communication. Throwing development and operational tooling into the chat conversation can ease the development pipeline, increase transparency and increase security by streamlining bug detection and remediation efforts.

At the heart of ChatOps are bots, scripts and chat clients; many are pre-built and open source. In this article, we’ll review a completely open source method for building out your ChatOps setup. We’ll cover integrating with Hubot, using CoffeeScript commands, and how building custom scripts can ignite ChatOps in your own environment.

Why Open Source for ChatOps?

Many arguments have been given as to the benefits of open source. Building upon open source inherently evades vendor lock-in, enabling more security and service longevity. Furthermore, to avoid reinventing the wheel, forking existing open source ChatOps projects naturally will be more efficient than purely greenfield initiatives.

Open Source Chatbots

There are many Chatbots available for use; each with unique capabilities, varying types of integrations out of the -box, and different ways to extend functionality with custom scripts. Take Lita, for example, an open source chatbot built with Ruby. It works with IRC, HipChat and Campfire. Many other open source chatbot options exist, such as Errbot, Jarvis and Lazlo.

Example: Hubot

By far the most adopted open source ChatOps companion is Hubot. Designed and open sourced by Github, Hubot takes market share in the ChatOps discussion. Described as “a customizable, life betterment robot,” Hubot is written in Node.js and takes commands with CoffeeScript.

Using Hubot, developers can initiate commands with Hubot scripts to perform actions such as post images, translate languages and integrate with maps, but also initiate vital commands to your favorite DevOps cloud tools. A full catalog of scripts can be found here, and it’s quite easy to craft your own CoffeeScript commands as well.

Example Hubot Scripts

The community scripts that support Hubot are similarly open source, meaning that you can repackage these implementations to suit your own needs. Let’s take a look through the catalog of Github-supported Hubot scripts to see what sort of pre-constructed extensions we can seamlessly add to a Hubot environment.

With Hubot, you can ping your major cloud development platforms, such as Heroku. Some example commands for returning status of issues on Heroku include:
```
hubot heroku status - Returns the current Heroku status for app operations and tools

hubot heroku status issues &lt;limit&gt; - Returns a list of recent &lt;limit&gt; issues (default limit is 5)

hubot heroku status issue &lt;id&gt; - Returns a single issue by ID number
```
Or perhaps you want to conveniently check PagerDuty from your chat client to see who is on call within your incident response team, or to gather details on current incidents. Hubout has a script for that. Using pagerduty.coffee, some example requests might be:
```
hubot who's on call - return the username of who's on call

hubot pager me trigger &lt;msg&gt; - create a new incident with &lt;msg&gt;

hubot pager me incidents - return the current incidents

hubot pager me notes &lt;incident&gt; - show notes for incident #&lt;incident&gt;

hubot pager me problems - return all open incidents
```
Another example could be direct interaction with the Twilio API for sending SMS. Using sms.coffee you can initiate a command with the following syntax:
```
hubot sms &lt;to&gt; &lt;message&gt; - Sends &lt;message&gt; to the number &lt;to&gt;
```
Configuring sms.coffee is easy, all you need to insert are:
```
HUBOT_SMS_SID

HUBOT_SMS_TOKEN

HUBOT_SMS_FROM
```
Of course, there is no shortage of Gifs, cat memes, and other scripts to add some humor to your workday, such as mustache insertion using image detection.

Generating Your Own Hubot Scripts

Aside from using third party scripts, you can always craft your own. To be an executable Hubot script, your code must be in .coffee or .js, and it must be in the correct directory (src/scripts and scripts by default). It must also export a function, as in the following:
```
module.exports = (robot) -&gt;

# your code here
```
Essentially, Hubot listens to all chat communication; it will hear commands and respond accordingly. To configure what it must hear in regards to your script, you must specify what to listen for, and what to respond with. For example:
```
module.exports = (robot) -&gt;

robot.hear /badger/i, (res) -&gt;

# your code here

robot.respond /open the pod bay doors/i, (res) -&gt;

# your code here
```
For further details, see the documentation on Scripting here.

Getting The Most of Chatbots

Once integrated into a chat platform such as Slack, your chatbot configuration can truly thrive. Given the wide breadth of community generated and Github-maintained scripts, DevOps teams have near unlimited potential for uniting their tooling into a single, human-readable CLI. Another benefit of choosing open source tools for such projects is that you can detach your bot and integrate with whatever chat client you prefer.

ChatOps can add fun and efficiency to the remote workspace. We’ve covered high-level methods for adopting this into your team’s space, and hopefully, a helpful foundation into the power of open source for streamlining the power of ChatOps.

— Bill Doerrfeld
October 16, 2018
Modern Software Development Helps KPI Achievement
A new survey by Frost & Sullivan in collaboration with CA Technologies clearly shows that business executives believe modern software development helps them achieve KPIs. This is the latest in a string of surveys showing that modern software development practices such as DevOps result in higher-performing organizations, more profits and greater KPI achievement.

Key findings of the survey show that organizations with more mature programs are:
- Eight times more likely to declare that applications are very good at supporting the achievement of
  business KPIs;
- Seven times more likely to say their apps are completely integrated to enable functionality, data
  sharing, authentication and security; and
- Able to achieve two times’ higher profit growth.
Ashok Reddy, GM DevOps CA Techologies

I spoke with Ashok Reddy, Group GM, DevOps at CA Technologies about the findings. In addition to the key findings above, Reddy emphasized another key point: The survey showed that in organizations with modern software development programs, business executives outside of IT are key software decision-makers.

Traditionally, IT was viewed as servicing the rest of the organization as their customer. A key constituency of this customer base would seem to be non-IT business executives. They recognize that software and applications are so important to achieving KPIs. They are moving beyond just being a customer of IT to actually being involved in the software development process itself, according to Reddy.

Some Troubling Findings

Not all of the findings from the survey are rosy, though. Pressure to release software endangers quality and security, according to 69 percent of the business executives surveyed. More than two-thirds of respondents said that security is sometimes overlooked to expedite development. Software issues negatively impacting KPIs was cited by more than half of the respondents.

With modern software development practices becoming so important, the findings above seem logical—logical, perhaps, but not acceptable. We must continue to strive to make security a more organic part of the software development process. Security concerns cannot continue to be overlooked because they are a drag on software development. One of the key points that I believe about DevOps and modern software development is that you can have more velocity, speed and security by following these practices.

All in all, this survey is yet another brick in the wall showing that organizations around the world adopting modern software development practices such as DevOps, Agile, etc., are outperforming their competitors who don’t. It is quickly becoming a case of DevOps or die.

— Alan Shimel
October 15, 2018
DevOps World | Jenkins World 2018 San Francisco: Video Interviews, Day 2

The recent DevOps World | Jenkins World 2018 San Francisco conference offered a bevy of interesting conversations with folks from all corners of the DevOps space, from testing to automation to security and beyond. All of those conversations are available for viewing on DevOpsTV.

My two days in the Broadcast Booth on the show floor at the conference was busy, busy, as a number of attendees stopped by for a quick chat with Jayne Groll, CEO of DevOps Institute, or me. Topics ranged from the growing influence of artificial intelligence to the importance of testing and DevSecOps. Below is a recap of the Day 2 video interviews (Day 1’s recap is available for viewing here):

Contrast Security Discusses DevSecOps

Mahesh Babu of Contrast Security stopped by to discuss his company’s technology, which helps an app protect itself through agents that constantly monitor the code to see in real time any problems within the application.

Smart Bear Talks AI and Testing

Daniel Giordano of SmartBear chatted with us about how his company is using artificial intelligence technology in its testing products to test things beyond objects such as images and charts.

Perfecto’s Kinsbruner Debuts Continuous Testing Book

Eran Kinsbruner of Perfecto talked with us about the launch of his book, “Continuous Testing for DevOps,” which he wrote in conjunction with CloudBees.

JFrog Offers Take on DevOps Culture

Baruch Sadogursky of JFrog discussed the challenges in DevOps with respect to culture and ways companies are finding ways to make the cultural change.

Electric Cloud Offers Technology Update

Electric Cloud’s Sam Fell stopped by the Broadcast Booth and offered up an update on the company’s technology stack and its potential impact on the development environment.

IT Methods Talks Cloud Adoption

Paul Goldman of ITMethods talked with us about the evolution from on-premises to cloud deployments and the various reasons why organizations are making the change.

Go2Group Offers Service Provider Perspective

Mike Maheu of services provider Go2Group discussed the trends his company is seeing regarding organizations that are undergoing DevOps adoption, including the tooling and practices.

Services Provider Zivra Talks DevOps’ Global Impact

JJ Alvarez of Zivra, CloudBees’ Partner of the Year, talked with us about the global expansion of DevOps and the recent surge of Latin American and South American countries adopting DevOps principles.

SauceLabs Talks Testing and Security

Clint Sprauve from SauceLabs stopped by to discuss the correlation between testing and security in DevOps as companies struggle to maintain quality in their application development process.

Releasing the Gitcracken

James Quigley of Gitcracken talked with us about the role of his company in helping developers improve their coding performance and productivity and increase the comfort level of less-experienced developers.

Twistlock Talks Kubernetes

Matthew Barker of Twistlock discussed the impact of Kubernetes on application development and trends he’s seeing in the Kubernetes space as a whole.

Pivotal’s Approach to DevOps

Pivotal’s Nima Badiey schooled me on his title and chatted about how his organization approaches DevOps with its customers, especially large enterprise companies that have legacy systems and mindsets.

NowSecure Talks Mobile Development

NowSecure Chief Mobility Officer Brian Reed discussed trends in the mobility space, including the use of mobile app projects as a “gateway to DevOps.”

— Charlene O’Hanlon

October 12, 2018
Scripts in the Development Pipeline: Best Practices for Avoiding the ‘Scriptocalypse’

The use of scripts as a key tool in the average developer’s bag of tricks has altered the development pipeline in significant ways. It has even led some organizations to outsource their entire team to manage the glut of scripts that have been developed over the course of time.

To help companies move beyond the “scriptocalypse,” we recently participated in a webinar with our friends at Tricentis. Sunil Mavadia, global head of customer journey at Electric Cloud, and Thomas Stocker, director of product management at Tricentis, walked through best practices to follow to avoid the scriptocalypse. Here are some takeaways from their discussion.

Improve Process Robustness and Scalability

Of course, everyone wants to improve their process robustness and scalability, but how? One of the most effective ways of doing this is to employ a tool that helps orchestrate your releases and provides reusable objects. This reduces risk because you no longer have to write scripts for every single application, which creates a cascading effect—not only do you write fewer scripts, but also you don’t have to maintain these scripts across the board. As a result, you are assuming much less risk across many levels of your technology and pipeline. Additionally, system-level visibility across all of your processes will increase—which has many benefits for your entire development life cycle.

Don’t Just Automate, Orchestrate

Many developers make the mistake of thinking that because they have scripts, they’re automated. But to be truly automated, every action needs to be automated and driven by your pipeline. Your approvals, your handoffs … everything. Oftentimes throughout the release process, team members find themselves having to stop in the middle of their tasks to ask for approval. This only creates a process that interrupts the entire pipeline. But what if you could automate all of that?

A great quote from the “2018 Accelerate State of DevOps Report” that speaks to this says, “High performers automate significantly more of their configuration management, testing, deployments and change processes than other teams.” If you look at it purely from a team perspective, the high performers are those that have fully automated all their processes. While this can certainly sound like a daunting task, it’s best to look at it with an agile mindset—this is an iterative process. You have to start somewhere, while keeping the goal of 100 percent automation in view.

Not only should you be automating, you also should orchestrate your pipeline. This is critical. By automating and creating reusable objects, you can get to the point of using your pipeline as a service. Imagine reusing this particular pipeline for every application within your process, so you could have hundreds, even thousands, all using this pipeline and all these objects underneath that are all reusable objects. It’s a pretty picture, isn’t it?

Create a Value Stream Map

When you create a value stream map for a pipeline, you want to be very inclusive about who you invite in the room to create the value stream. Include representatives from release management, development, deployment engineers, team leads, executives and infrastructure engineers. Basically, anyone who has “skin in the game” for your release should be present.

Once you feel you have a solid representation of who is impacted by your releases, sit down and draw out the entire process. This includes figuring out what each script does. While that may be a big task depending on how your pipeline is currently structured, there’s actually a lot of opportunity there. For example, you might find there is one application for which you use one script to do that deployment. Typically, that script is duplicated for another application and so on. Imagine doing that 100 times. You’ll have 100 scripts or variations of that one script for your 100 applications. That’s an obvious and beneficial place to deploy a bit of automation.

This is also a great time to understand what tools you are using for each step. When you’re jumping from toolset to toolset, it can be difficult to get a holistic view of how this is impacting your overall performance without a complete picture of the value stream. When you have that picture, you can start to ask yourself questions such as, “What are all these tools that we interact with that we can integrate into the pipeline? How are we handling approvals?” By including detailed sequencing timelines and identifying bottlenecks, you can realize some impactful efficiencies.

Finally, creating a value stream map gives you an opportunity to organize your scripts. Laying out the entire value stream can give you a picture of the variety and quantity of scripts you’re running—whether they are CI scripts, deployment scripts or test automation scripts—and bucket them in a logical way.

Identify Redundancy Dependencies and Bottlenecks

Of course, identifying (and hopefully rectifying) dependencies and bottlenecks is a good best practice for any aspect of your development pipeline. But it becomes even more important in the context of using scripts. If you have one application dependent on another application, it’s almost impossible to script. For example, imagine you’re trying to do some testing with two dependent apps. If you don’t have the right versions across both, you can’t test one because the other one is not up to speed or it hasn’t been updated in an environment. Something even as simple as that can be really disruptive and make scripting very difficult. By understanding where your dependencies and redundancies exist, you can take the first step toward solving the issues they present.

Scripts are one of the most effective ways of streamlining your pipeline, but they need to be used in a way that will allow your organization’s applications to be scalable and sustainable. By following some of the best practices outlined above, your organization can use scripts like pros—and avoid the dreaded “scriptocalypse.”

For more insights watch the full webinar here.

— Anders Wallgren

October 11, 2018