The DevOps developer puts it online – stop the craze and start automating!

Source:-mashviral.com

Let’s face it: the pace of software releases is getting more and more frantic. Two years ago, 35% of companies responding to a Cloud Native Computing Foundation survey published software daily or weekly. In the most recent CNCF survey, that number increased to 65%. Respondents with daily release cycles increased from 15% to 27% during this time.

Photo: HubSpot

In busy software development stores, it’s great to have skilled and intelligent people who are capable of developing smart business solutions. But with releases launching every day, maybe even hours, the best of the best finds it difficult to stay ahead of this process, which often involves fixing solutions again.

That is why it is urgent to implement a highly automated, continuous delivery / integration strategy (CI / CD), according to Andrew Davis of Copado and author of Mastering Salesforce DevOps. In a compelling session on Dreamforce 19, he outlined the challenges that companies now face, and said that effectively accelerating development life cycles “requires a combination of thinking and good tools”.

Although Davis’s conversation was directed at Salesforce teams, their views resonate across the broader field of IT. Usually, he says, relate, software deployments follow six steps that form the basis of DevOps:

Understand what users need.
Build it.
Make sure it works.
It ensures that it works well with the rest.
Make sure you don’t break anything else.
Deploy it to users.
The final three steps are where many development teams often stumble, according to Davis. “The happiest thing about writing code or doing complex administration tasks, etc is when you have your whole head, and you can see how it all fits together, and the world disappears, and you know exactly how your organic works, and any you can ask for any change and you can fix things. Developers live with that sense of happiness – knowing everything and fixing anything. “

The catch is, a particular project is over, distractions are distracting, new projects are starting and time has passed, Davis continues. “Does this disappear from your working memory? It may be a day, a week or a month late before you know you have broken something. After three weeks, you forgot that you even created this. And if you remember you built it, forget how you built it, forget exactly why you built it. You can make another change, but it can take another three weeks until you can get back to the users. ”

Multiply that by hundreds or even thousands of change requests within a large organization, and it’s easy to see how things can go wrong.

DevOps brings flow and order to this potential insanity, and Davis reduces it to a three-step process: development, innovation delivery, and operations. “There’s the development bit where you create new things and operations, where you explain things in production,” says Davis. “In the middle is this process, the delivery of innovation, which is delivering all the beautiful innovation on production.” This is why a highly automated DevOps process is required, allowing the manual tapping required for the middle phase between development and operation to be extracted and systematized.

Davis illustrated how an effective DevOps and CI / CD strategy should be:

Every developer and team in a company merges into a common code base or trunk at least daily.
As soon as the code base is changed, it runs automated testing.
If tests fail or things break, they fix in ten minutes.
Davis says the ability to automate the test phase, to test quickly, is key to CI / CD efforts. “Developers need quick tests where they can get feedback while still having all that discomfort in their working memory.” These tests should be designed to provide “real-time information to developers in less than five minutes.” You can perform more complete unit tests.

The aspect of continuous delivery also needs to be addressed by another problem called “configuration drift,” in which “environments are de-synchronized for many reasons,” said Davis. “Maybe people are making changes in production that don’t make their way to development and testing. Or you have changed development environments, but there are a lot of junk in the sandbox you have had since 2006, and it’s not renovated and you know it doesn’t quite match production. ”