These approaches – usually referred to jointly as CI/CD – are well-known in the development community. By using CI tools to build code as and when commits are made and CD tools to automate testing and deployment, businesses can reduce the time, effort, and risk involved in the path that code takes from a developer’s mind to its production environment.

Once properly configured, these tools effectively turn a long list of disparate tasks into a domino run. Rather than having engineers shepherd new code through the various steps involved in building, testing, and deploying – with all of the infrastructure and compliance management labour which goes along with them – a code commit becomes a trigger for the full sequence of necessary events.

Thinking beyond the tool

There are now any number of software options that can be used to implement CI/CD, from the grandfatherly open source solution of Jenkins to options from disruptive providers such as Gitlab and enterprise packages such as Atlassian Bamboo. Selecting between these competing paths towards CI/CD can quickly come to seem like the central challenge for development teams looking to accelerate their production – and this article could take on the task of a comparative analysis of the major options.

There is a real risk, however, that focusing on identifying the ideal CI/CD technology means failing to see the wood for the trees. Even as CI/CD establishes domino effects within the development lifecycle, it has ramifications that go well beyond the software environment.

Instead of being something that you can buy off a shelf, a successful enterprise grade CI/CD solution requires the undertaking of significant organisational change, including transformation across areas as diverse as people, process, culture, and tooling as well as technology. It is my experience that enterprises frequently underestimate the impact that implementing CI/CD can have, especially for legacy or existing applications. There are, therefore, questions you need to ask which are at least as important as picking a software offering.

Coping with computational demands

Let’s take physical infrastructure as a first example. In a simple scenario, implementing CI might mean increasing the build server’s workload from one to ten builds per day. Do you know that the server can execute builds at this rate, and how it will react when multiple developers commit code and builds queue up?

Even if the server does have sufficient resources, each of those builds will need to be stored in an artefact repository, creating a significant additional storage demand. Meanwhile, it is also likely there will be an increase in the load for unit test execution. If a unit test cycle takes, say, three hours, are you certain that those cycles can be executed at a higher rate than new code commits and avoid a growing backlog of necessary testing?

These issues intensify when the pipeline matures to include CD. Beyond unit testing requirements, the functional and performance testing processes required for application deployment themselves commonly run for hours or even days. As resource needs multiply – and teams acclimatising to CI/CD begin to commit ever more frequently – it becomes necessary to automate not just delivery but the provisioning of net new infrastructure. Here, teams will find the remit of continuous methodologies growing to include Change Configuration Automation (CCA), ensuring that appropriate environments are available in a system that can react to periods of higher demand.

Managing CI/CD

This brings us to the second example of knock-on effects that teams might not foresee: organisational management. With CCA supporting the CI/CD workflow, development and testing teams will be provisioning their own infrastructure, perhaps using virtualisation, containerisation, or cloud systems. This raises several financial and legal issues that need to be accounted for prior to introducing CI/CD.

Is there a budget in place to address the increased costs of new system instantiation and ongoing support? Are there licenses available to run several new systems in parallel? Are there policies in place to decommission systems that are no longer needed while maintaining audit needs? Failure to attend to these adds cost and risk, undoing benefits which CI/CD is meant to introduce.

The managerial questions extend further in organisations where multiple development workflows operate alongside one another, with varying degrees of interdependency. If two or more applications need to be delivered to end-users in series or in parallel, due to the nature of the dependencies between them, how will CI/CD account for that? How flexible will it be if some of those applications are employing more traditional delivery models? And how will it sit in the context of formal change governance models which are umbrella across several applications?

Keeping the human in mind

Thirdly, and as in any transformation exercise, it is vital not to forget the human at the heart of all of this change. The short-scale feedback loop of CI/CD, testing and verifying code at each commit, can generate a satisfying sense of progress and achievement even as it alerts teams to potential issues earlier in the cycle.

Yet, the flip side of developers pushing commits which point back to them several times a day is that if and when they do fail, it can quickly start to feel like being put on a wall of shame. This is just one example of how the culture shift can add demotivational elements to the workflow. A reworking of overall quality metrics may also need to be considered, ensuring that later defects issued against the build and peer review of code continue to be measured alongside immediate statistics on build success or failure.

The path to success

The good news amongst all of this is that, while there are many complicated questions to respond to in order to successfully introduce CI/CD, there are also many people who have already been on that journey, and consulting with experienced providers will help to highlight likely issues and the most productive solutions to them.

Ultimately, due attention to tools, management, and counsel will help you arrive at a position where you’re ready to push the first domino in your CI/CD system.

Written by Julian Fish, director of product management for SCCM and Application Release Orchestration, Micro Focus

The post Get set up for Continuous Integration and Continuous Delivery appeared first on DevOps Online North America.

What can you tell us about your expansion into Europe and what it’s going to mean for your firm?

We’ve been doing this for about 8 and a half years and we work through a “bottom’s up” motion where we allow developers to use our platform for free and get familiar with how the firm works. When they are comfortable they start to pay for us. As a global firm, here in Europe, we have about 20-25% of the business. [The move] is to get closer to the customers and as we get bigger, we are trying to build teams to get closer to these customers, help them along and help answer their questions without making them stay awake to speak to someone in California.

Why did you choose to move to London specifically?

Of our European customers, the UK makes up about half. We already have lots of big and interesting customers over here and so we had natural gravitation into London, to begin with. It’s a big and sophisticated technology hub here in Europe and globally and it’s a great launching point as we head into other markets and so it ended up being a really good fit for what we are trying to do.

How do you feel Brexit might affect what you are trying to do?

We thought about our expansion and Brexit, but given the size of the UK market and the amount of customers we have in the UK, we are always going to have to have a presence here. I think the question for us came down to, how are we going to support the rest of Europe? We already have a number of developers making a footprint in the rest of Europe and so if we are in a situation where we need to support that, then that’s what we will do.

EMEA General Manager Nick Mills adds:

Although there are questions where London and the UK will stand in tech because of Brexit, it clearly hasn’t been a problem in the past three years since Brexit was decided. London still is 2.5 times the size of any other tech hub in the region and is still growing. There are strong reasons for that. There are strong developers… There is a strong ecosystem, particularly around venture capital start-ups…combined with investors… and that community isn’t going anywhere. There might be ways in which you choose to set up your company, but luckily, we are already pretty established and have a lot set up to be able to capitalise on the growth.

Will you be partnering with anyone in the move?

We are coming in directly and have a pretty good relationship with the customer. Our plan is to work directly with developers as we grow.

In terms of tech, what kind of tech do you use that enables your firm to work the way it does?

We are cloud-native at the core, so we were really built for the cloud-based world. We use a multitude of different clouds to be able to support that. Testing itself to be able to help and build different software tends to be an extremely spikey business, people tend to see the tests at the same time and then go dark when they are not working. We tend to be indicative of the big trends in terms of software development. We are big Kubernetes users, we are big fans of all the various hashicorp technologies. We have written in a bunch of crazy languages. We tend to be fairly out in the edge in terms of pushing technologies and seeing where everything breaks. I was talking to somebody who said, “it’s really easy to find technologies to do ten things at once, but once you start doing things a million times at once, everything gets a little more challenging”. So, we are one of those types of companies.

Particularly thinking about things like software testing, which points do you think are most important to focus on?

The core part of the CI process generally is to test small batches often. So, you want to be able to test small batches when you can and as frequently as you can. Because it both allows you to identify when something breaks, you know where to look, and the more often you test, the more stable your build gets. Testing’s a muscle, the more you exercise it, the stronger it gets. That is really the heart and soul of a continuation project. Once you have established your overall build, the next logical step is continuous delivery. Because if you can build it and test it and you know everything is good, you might as well get it into the hands of the customer as soon as you can.

What we are seeing more and more is a big move towards microservices. So, an idea of taking your big monolithic apps and breaking them down into individual live services instead of having one code base that’s servicing your application stack. You might have dozens, if not hundreds of services, that essentially, co-ordinate themselves and work together on an application. As you start to move into that world, testing across services is both complicated as well as incredibly important as you now have to make sure that all the services can work in coordination to make sure they can deliver whatever it is you are working on. The more and more services you have, you then have to test those services in production. The idea used to be… that everything should test the same. But when you get into these microservice environments, you no longer can produce a facsimile of your production environment because all these services are moving in different services and in different ways. Many companies now complete actually complete the testing process in production… and that requires a different set of skills but as more and more people head into microservices, I think that probably going to be the predominant pattern that you will see.

Is this something that your company is doing?

It’s something that we do internally, but it’s also something that we support on behalf of our customers. We are really agnostic to the type of technology and architecture that our customers use. If they build big monoliths, fine, if they use small microservices, we can support that as well.

What’s your advice on how to improve a team?

From a team perspective, the idea of microservices really runs hand in glove with agile development and team sizing. So, the idea is that teams tend to work best when [there is a smaller team]. This is the same when it comes to software in that the bigger the things get, the harder they are to test. When you’re getting smaller teams, you’re getting smaller services. Your application starts to mirror the way teams are constructed. However, as you get into microservices, what becomes incredibly important is ensuring teams are working off the same sets of tools and the same baselines. Regards of what kind of teams you are trying to set up, you want to be able to centralise and standardise the way a service gets set up. So, they are using the same tools, the same controls, the same standards and they are using the same patterns.

With all your experience, what are the best pointers you give?

It all depends on where you are as a firm. Using core CI practices are good in terms of testing frequently and testing often and test in small batches. The second is to adopt cloud-native if you can. Also, focus on the thing that makes you special.

The post “We are really agnostic!” Why this US cloud firm is making waves in Europe. appeared first on DevOps Online North America.

The new world of modern software delivery, ushered in by the impact of digital disruption, offers tremendous opportunities both to improve solution quality at the desired speed and to develop new capabilities. However, as testers, we need to acknowledge that in order to ensure that software quality remains at the forefront of the mindset of everyone involved throughout the development lifecycle, our role and approach will have to change.

Cultural change is required

There is a general recognition that the cultural changes required for an organisation to successfully move into the world of DevOps/CI/CD can prove a much bigger barrier than the technical challenges.

To survive and thrive in this new world we need to develop a continuous testing culture across our function, complimenting and supporting a wider continuous delivery culture. We must become the champions and advocates for testing and quality activities across the lifecycle. This should bring what we have long sought – involvement right from the outset.

Rather than managing towards ‘hand-offs’ into segregated testing phases, we need to foster the approach of collaborative work and joint problem-solving.

The wider culture, typically adopted in this modern delivery world, of trying new approaches and tools and discarding those things that don’t work/add value, can help us in testing to also be more innovative. We can, and perhaps should, become more comfortable in experimenting with new techniques and ways of working in the quest to improve quality.

New friends and allies

The advent of DevOps also brings the opportunity to work more closely with our colleagues in operations. We share goals of protecting production and the customer from poor quality and resulting outages. Often those areas that the operations team are concerned about and want to see closely monitored are areas that we should be focussing our quality lens on too. On the flip side, the instrumenting and tools we utilise in testing may also deliver benefit to our operations colleagues.

Single view of the risk

In this world of modern software delivery and improved collaboration, we have an opportunity to develop a single, joint view of the level of risk and where this lies across the solution landscape. When we have achieved this single view, there should be much greater buy-in from our technical colleagues and senior stakeholders into our proposed approach to testing, which should be closely aligned to that same view of risk. In turn, this should avoid any suggestion that the scope of testing/QA is inappropriate and might even ‘kill the business case’.

Establishing a ‘ruthless automation’ mindset

The challenge in this new world for all disciplines including testing/QA is to think about how to automate all tasks as far as possible almost as soon as they are identified. This has been referred to by Forrester as ‘ruthless automation’. This approach of maintaining a constant eye on the challenge of frequent perhaps daily or even more frequent releases is an important shift in mindset.

Transformation from testers to quality engineers

It has been suggested that what is required to deliver solutions is actually ‘T-shaped technologists’, individuals with a dual focus. Firstly, they have their specialism, perhaps in development or more likely in our case test automation, exploratory testing or test data management, but then secondly, they must have the overall end-to-end delivery focus required. This means we will have the opportunity to develop new skills, become more technical if we have the aptitude/desire, but certainly move closer to the other functions.

We need to add value by advocating and driving quality across all of the different delivery functions and activities. From the initial story definition, through to the method of deployment, we can champion quality. This must include ensuring that the final delivery we are working towards meets all the necessary quality criteria. We have the opportunity now to re-invent ourselves and become quality engineers rather than merely testers.

Avoiding the perils of burn-out

When we establish what constitutes a sustainable pace of delivery, we need to consider not just technical considerations but our engineers and avoiding them becoming stretched beyond reasonable work commitments.

As managers, we need to ensure our quality engineers have a work/life balance that is appropriate. The benefits of an improved delivery speed could be very short-lived if in the process our talented engineers suffer ‘burn-out’ and consequently become less productive.

Embracing the opportunities

The new era should ultimately (appreciating this won’t happen overnight!) bring with it a clearing of the technical debt that previously meant being stuck with troubleshooting problematic legacy systems. This, in turn, should mean greater opportunity for our teams to work on more exciting new work.

Professional testers and those working in QA share a genuine passion for delivering quality solutions. The new world of modern software development offers us opportunities to develop new skills and have a greater influence, and ultimately play a pivotal role in delivering better quality at the speed demanded by today’s demanding and perhaps more discerning customers.

Rather than seeing the new delivery methods of DevOps/CI/CD as a threat to our existence, we need to evolve our teams and individuals to meet the challenge. Ultimately, we need to transform ourselves to become fully fledged quality engineers and in the process, earn enhanced trust and respect from our colleagues.

Written by Richard Simms, Test Architect, ROQ

The post Embracing the opportunities of DevOps appeared first on DevOps Online North America.

Nearly 40% of respondents said they are concerned about inappropriate pricing and licensing for the cloud, while 34% said they are worried about the lack of integration preventing cloud automation.

Despite this, almost all survey respondents see value in cloud-specific firewalls, with 74% of respondents saying integration with cloud management, monitoring and automation capabilities is the most beneficial cloud-specific firewall capability.

Automation capabilities

The survey also studied how security automation benefits DevOps teams. 56% of organisations surveyed have adopted DevOps, DevSecOps, or CI/CD development methodologies (continuous integration and continuous deployment).

Of the above, 93% faced challenges integrating security into those practices, while 67% reported existing security solutions was the top challenge.

Tim Jefferson, VP public cloud at Barracuda, commented: “We’re continuing to see questions and concerns around how organisations should approach security with their cloud deployments, especially from larger companies.

Security tools

“While there are a number of reasons for this, moving to the cloud requires a new way of thinking about security for organisations that are used to operating under traditional data centre architecture.

“Using security tools specifically designed for the public cloud can actually make a business more secure than they were when they operated purely on-premise.”

The Firewalls and the Cloud survey was conducted by more than 600 IT security professionals and created by Dimensional Research.

Written from press release by Leah Alger

The post Firms raise concerns over firewalls in the cloud appeared first on DevOps Online North America.

This ability to automate code coverage tracking across platforms is another example of how Compuware empowers enterprise IT to apply essential agile, DevOps and continuous integration/continuous delivery (CI/CD) disciplines to core systems of record and systems of engagement.

Code coverage metrics provide insight into the degree to which source code is executed during a test, allowing IT teams to understand the scope and effectiveness of their testing as code is promoted towards production.

The new integrations automatically feed code coverage results captured by Compuware Topaz for Total Test into SonarSource SonarQube, giving DevOps teams an “accurate, unified” view of quality metrics and milestones across platforms.

More specifically, integration between Topaz for Total Test and SonarQube now enables DevOps teams to:

• Gain insight into the coverage of code being promoted for all application components across all platforms
• Improve the rigor of digital governance with strong enforcement of mainframe QA policies for coding errors, data leakage, credential vulnerabilities and more
• Shorten feedback loops to speed time-to-benefit and more promptly address shortfalls in COBOL skills and bottlenecks in mainframe DevOps processes

Today’s announcement further delivers on Compuware’s promise to mainstream the mainframe, providing a familiar and intuitive mainframe development environment integrated with state-of-the-art DevOps tools for developers newly engaged as mainframe application stewards.

“Our customers run their businesses on the mainframe, so their proven COBOL applications are of extraordinary value and importance to them,” said Chris O’Malley, CEO of Compuware.

“That’s why we are serving our customers by aggressively delivering the new solutions they need to achieve their ambitious goals for digital transformation, just like an authentic mainframe software partner should,” he added.

Written from press release by Leah Alger

The post Compuware and SonarSource integrates COBOL code coverage metrics appeared first on DevOps Online North America.

Introducing DevOps is a big, challenging and complicated process. There are many obstacles, technical and organisational, that are likely to get in the way. Hardie highlighted some of the anti-patterns that are going to cause problems. These range from apparently simple technical items that can have big consequences down the line to the far greater people and organisational behaviour patterns that have to be confronted and changed.

Just because you’re “doing agile” doesn’t mean you can just overlay DevOps on top of it – the two are very different and not directly related. The decision has to be made as to how far you want to go with DevOps – are you ready for true “continuous delivery” and, if so, what anti-patterns are going to stop you? “To embed or not to embed, that is the question,” said Hardie.

Of course, tech is complicated and ever changing, but Hardie believes that it’s the culture and work pattern changes that are the hardest things to accomplish. Developers, ops, security, programme managers and delivery managers play a huge part in DevOps transition.

“If management have difficulty understanding certain tech it can be hard; they appear to worry about what is an information control, like agile, and CI/CD. They should understand and support the benefits and should be used to push organisational change top-down,” advised Hardie.

“The solution is to set goals, set targets, to buy-in and support essentials,” he added.

DevOps is about speed, and speed can deploy bad effects as quickly as the good. Microservices and Docker can bring extra security challenges, noted Hardie.

“Agile and DevOps together is a big challenge. Without agile DevOps is hard. Be very clear about what it is you want to achieve with DevOps – don’t do it because it’s fashionable. Make sure ABCs are helping achieve what you want to do, not what they want,” said Hardie.

Further concluding to other DevOp enthusiasts that tech is hard; they should start with codebase (if possible), shouldn’t introduce agile separately, should make all tests automatic wherever possible, and allow defect count reduction or code quality targets.

Written by Leah Alger

The post Wipro Consulting offers advice to tackle DevOps appeared first on DevOps Online North America.

Microsoft’s CEO, Satya Nadella, revealed that Microsoft is offering core technology to support serverless computing and containers as part of its DevOps strategy, at the Microsoft Build 2017 conference.

He explained how Microsoft’s container approach, using continuous integration and continuous delivery (CI/CD), has played a massive role in the company’s developer strategy, which combines testing developments.

“DevOps is supplemented by serverless computing, because it frees up IT operations staff and developers from having to set up and tune systems,” Nadella proclaimed.

“It will be the core of the future of distributed computing.”

Technology demonstration to inspire developers

Microsoft broadcasted a preview of its Azure Functions Visual Studio tool extension at the conference, to assist developers in building serverless apps, to inspire developers to use the tool into development flows.

“Azure Application insights support for Azure Functions preview provides telemetry information about codes, enabling developers to measure performance and detect issues with serverless apps,” added Vice President of the cloud and enterprise group at Microsoft, Scott Guthrie.

“The serverless computing preview extends Azure Functions to the cloud, so developers can leverage the serverless programming model on premises.”

The technology company also publicised a range of other technologies to help with transitions, including updates to its artificial intelligence (AI) offerings and database technology.

Edited from source by Leah Alger

Source: TheServerSide

The post Microsoft supports serverless computing appeared first on DevOps Online North America.