Continuous Build is an anti-pattern that I have often seen where a team will have what they call Continuous Integration (CI) in place but it only builds the code, there are no tests or static analysis run. Certainly, this is better not building but it leaves a lot of health check information on the table that is considered part of CI. Without this information, you can never really gain the confidence that your build is healthy. The whole goal of CI is to feel that your build is healthy so not tests and analysis means you aren’t going CI.

Just like CI, other DevOps practices can be hard to understand, implement, and get right. Even with the best of intentions, we make mistakes or misinterpret the implementation of a technique. Learn how to spot common DevOps anti-patterns and how to correct them. These patterns include

1. Continuous Build - CI without tests isn’t CI
2. Turn the unit tests off to build the release
3. Don’t automate that, it is my job
4. Different build process for developers and high environments
5. Different deployment process for developers, test environments and/or production
6. Not having a production-like environment to test in before production
7. Saving performance testing for the end of the release
8. Saving security testing for the end of the release
9. Never asking the users about the software
10. Only automating build and deployment, not testing
11. Not having retrospective
12. Restricting retrospectives to only the development part of the process
13. Running analysis and never looking at or acting on the findings
14. Reduce coverage or static analysis gates to get a build to pass

We have all experienced a time where we wanted to believe we could make an anti-pattern work but it never does. It is better to learn how to spot these and how to correct them than it is to try to keep tweaking a broken process hoping this time it will be better.

Application security is the poster child for third-class citizens in the software development world (behind Quality Assurance). DevSecOps is trying to turn that around and get more people, teams, and companies to care about security as our online and real-world lives become more intertwined.

Application security has a bad reputation with many people. It comes into the development process late and demands a lot. Who wants to deal with that? We have actual business value to get out the door. “Those things” won’t happen anyway. And when “those things” do happen, it will just become an exercise in finger-pointing and blame. Security is an ugly affair that no one wants a part of.

DevSecOps is a movement within the DevOps and Security worlds to reverse this decades-long drama by getting the people creating and updating software to build security practices into their process from the beginning, even before the code is written. This allows security professionals to become the evangelist of security practices where they can help the teams adopt practices and teach them how to use the tools to resolve issues themselves. No longer dependent on the specialists the teams can address security findings as they are found and make the workload manageable by spreading it across their implementation cycles-- proactively, not reactively.

Attendees will leave with an understanding of how to map security concepts onto a delivery pipeline, how to “sell” security concepts to stakeholders, and how automation makes it easier to gather security data and act upon it. Learn what is needed to get started with DevSecOps so that you can start creating secure software today.

DevSecOps uses application security practices that have been around for a while. The innovation of DevSecOps is incorporating security into the daily workflow of the team rather than leaving them to the end of a release like many legacy processes do. Shifting security left is made possible by the ability to automate many aspects of security testing and verification. DevSecOps leverages DevOps practices to make application security a first-class citizen in the practices of modern software product development. DevSecOps starts with a culture change mindset of cross-functional teams creating software through collaboration and fast feedback cycles.

The security in DevSecOps starts before the code is written by using techniques like threat modeling and risk analysis to help figure out who might want to attack you and how they might do that. This often ignored security practice can be enabled by following the DevSecOps practices of having a cross-functional team involved in the process from the beginning, including security professionals.

Next, DevSecOps maps application security practices into the build pipeline for a project in order to provide quick feedback about the security posture for any change made to the software. By using automation to allow the team to move quickly while maintaining confidence in the health of the code base, DevSecOps extends that health check to include application security checks. While automation can be used to make security data collection easier it is important to understand what security practices still require a human being.

This talk focuses on how, when, and where practices should be incorporated into a build pipeline to get the most value out of your security practices through automation. It explores what manual security work still needs to be done by a person and how to maximize value while minimizing the effort of human beings.

Elevator Pitch:

DevOps and Continuous Delivery call for a new look at agile software development best practices in order to maximize the efficient delivery of value.

Abstract:

Is your agile team “using DevOps” but still struggling to successfully deliver quality software to Production repeatably? Are you part of an agile team struggling with how to best support your DevOps (CI/CD) pipeline? As your practices mature it is natural to adopt best practices to improve the team. As the team gets better, the practices they follow need to change as well. Initial agile software development practices are designed to help the team bring order to the chaos of their projects. These practices help them become predictable and deliver working software on a regular basis. As a team progresses to continuous delivery, they need to focus on a new set of practices that leverages their build pipeline to build confidence in each build of the software. This session will lay out the best practices and process evolution to move from delivering at the end of a release, to delivering at the end of each sprint, and finally to delivering on a continuous basis.

DevOps Maturity levels

0 - Ad Hoc- rare builds with limited, if any, reliability. There is no build pipeline or any automation. Provisioning, deployment, or test are ad hoc.

1 - Continuous Build - builds happen on a regular or continuous basis but without tests. Teams know the software compiles but nothing else.

2 - Continuous Integration - Sufficient level of unit test coverage and static analysis gives the developers a high level of confidence that the software works as they intended it to work.

3 - Continuous Delivery - Software is deployed to an environment automatically based on passing CI and automated tests are executed in that environment. You have a build pipeline or are in the process of putting one together. The team has confidence that if the software passes all tests and inspections that the build might be a release candidate. The team will start experimenting with techniques like feature toggles to have selectively activated code in specific environments.

4 - Optimizing Continuous Delivery - making your build pipeline take less time using parallel builds and shifting tests left (doing some perf or security testing earlier in the process). An initial build pipeline is fully established and the team is focused on making the pipeline fast while increasing confidence in the result. At this stage the team wants to use techniques such as build step parallelization to shorten the build cycle and adding tests in targeted areas. The goal of this level is to have a fast build that, if it passes, the team feels it ready to go into production. The team will have defined practices around selectively activated code in defined environments.

5 - Continuous Deployment - The ultimate expression of a build pipeline where the team has such confidence in the pipeline and its ability to determine build health that all check-ins are release candidates and any build that passes all tests and inspections are automatically put into production. This also requires a healthy rollback process that the team has tested and is confident that it will work if needed. Most teams will have adopted practices that support their practice of releasing into production multiple times a day.

The goal of creating a build pipeline is to help the team progressively gain confidence in the software they are building. With each level of maturity the team is focused on developing best practices for delivery of software in smaller chunks. The best practices change with the delivery timeframe. Best practices for each timeframe include:

Release Delivery Maturity

• All work required to release software is completed in the release
• Functional test suite is used to perform regression testing
• Software is production quality by the end of the release with the goal of having software working at all times
• Since the release spans multiple sprints the production deployment timeframe is the release and the team uses progressive planning for a release

Sprint Delivery Maturity

• All work required to release software is completed in sprint
• Software is production quality by the end of the sprint
• Functional test suite is used multiple times a sprint or is continuous during the sprint
• The sprint is the release timeframe for the team but the team may have plans that span multiple sprints
• The team may use branches or feature toggles to mange feature development

Continuous Delivery Maturity

• Software is always at production release quality, the goal is for the software to always be releasable
• All automated tests and inspections are continuous
• Human required processes are still performed but not in the path of release, ex. Accessibility testing
• Feature activation is managed by software techniques like feature toggles
• The release rollback process is matured and tested on a continuous basis

Examples of teams progressing through build pipeline maturity

Forge.mil - started with six month plus release cycle with no automation,through a series of incremental improvements we reduced that to releasing after every sprint using a totally automated process

REProfit - greenfield project that we took over and built out a build pipeline immediately. Developed a Continuous Deployment pipeline that took around 2 hours to go from check in, to released in production.

Abiomed - Embedded medical device with no automated build or pipeline. Created an automated build process including automated testing and a Continuous Delivery pipeline that deployed to test environments that ran test automation with every successful build.

Elevator Pitch:

Agile Transformation is harder than it needs to be because we often find ways to consciously or subconsciously sabotage our efforts if we can recognize this behavior it is possible to intervene and make a change for the positive.

Abstract:

Have you ever been on a project where it seems like team members are preventing the team from getting better? Why do they do that? I don’t know either- a psychologist might have to answer that. What I can tell you about is my experiences in seeing teams become their own worst enemies and unwittingly sabotaging the projects they are trying to make successful. My goal is to help you realize when you or those around you are behaving in a way that is going to lead the team plateauing or even failing. I have often found that many teams can get stuck, or plateau, at a certain point along the continuum of agile maturity. These teams can meander around without getting better or even changing anything for long stretches of time. I have also worked with teams that put so many hurdles in their own way that they had no option but to fail. They often fell back into old patterns and gave up hope that things can get better. As an Agile Coach, I have often felt that one of the most valuable things I can share with the people I coach are my failures. I have worked on Agile projects for a long time, and I have failed in many different ways. Having been through failure, I have learned that to keep getting better you have to recognize the things that you do that lead to plateaus and failures to overcome them. This talk is for coaches and team leads who want to make sure their team isn't getting stuck in a rut, or who are trying to get out of a rut with their health and sanity intact.

Failure signs and examples

No process is defined and followed

• ex. Projects that claim to be agile without any experience or training, or doesn’t have basic agile practices such as retrospectives, I.e. we are agile because we have hour long daily standup meetings.

Process practices are ignored or removed with no compensating practices

• ex. Agile practices hold each other together, supporting each other by the value they bring to the project, some teams decide to not do some practices without doing something else to get that value, for instance pair programming provides code review and knowledge transfer, many teams don’t pair program and don’t do code reviews and or knowledge transfer.

Automation is not valued or planned into work

• ex. We will automate tests later. Often that later never comes and the team is left with a code base that is hard to maintain and change because you don’t know what your changes break.

No stakeholder expectations management

• ex. The only way a project can negotiate scope and or schedule is to actively manage stakeholder expectations. An example of unmanaged expectations is the PO that never says no to a feature request or the executive that decides what must to delivered and when it must be delivered.

Quality and testing practices are an after thought or short changed on schedule

• ex. Teams that don’t complete sprint commitments because the testers get coded stories too late in a sprint to do all the required testing and the rest of the team isn’t held responsible to help test.

No negotiation allowed in deliverables and or schedule

• ex. Executives that dictate all of the terms of a project before a team is even selected.

The team doing the work didn’t estimate the work but are held to an estimate

• Many government projects have such a long procurement cycle that no one from the proposal team is put on the project.

Part time team members are in the critical path

• ex. Sometimes people with special skills are needed for a part of a project. If the person is part time but their work is in the critical path the project is in trouble.

Heavy team turn over

• ex. Heavy turn over is a sign of a project that isn’t on track, even if it hits its deadlines the quality and output will suffer.

Political motivations more important than team’s ability to do work

• ex. If the team is setup to fail for reasons outside the team, they will most likely fail.

Distraction from issues outside the work that needs to be done

• ex. Scrum Masters that don’t shield the team from issues outside the work that needs to be done during a sprint will end up with a team that doesn’t hit the mark.

Examples of what can be done to avoid failed projects:

Focus on shielding the team from outside influence

• Have the team focus on the things they can control and prevent outside issues from distracting the team.

Negotiate delivery with the team

• The team can develop an understanding of what it can deliver. Trying to make the team do more is going to lower quality and potentially make the project take longer.

Management of stakeholder expectations

• Stakeholders always want more, that is their job. Let them ask for anything but set their expectations on what is really going to happen.

Focus on technical excellence, quality, and automation

• If you want your teams to get better, have them focus internally on things they can control like technical aspects of the project including quality and automation.

Hire motivated team members and make it possible for them to work

• People who care about what they are doing will always be better than the cheapest people that don’t care. Hire people who care.

Maintain a progressive planning pace for getting requirements ready

• Agile requires planning at different levels, skipping a level for any reason means there are going to be disconnects between your stakeholders and the people doing the work. Disconnects means the project will not product the results you want.

A large part of the success of agile adoptions is due to the automated testing approach used in agile projects. Because many of these techniques were pioneered in the development of web applications it can be hard to see how these techniques can be leveraged for a project where the software being built is for an embedded application. Discover ways to leverage agile testing techniques for embedded systems. Whether you are building a medical device, embedded controller, or Internet of Things device learn how to leverage these testing practices to create fully automated tests that fit into a DevOps build pipeline and help your team create higher quality, more reliable software. Test automation is the best way to maintain and execute a comprehensive suite of regression tests that allows you to take back control of your testing process while increasing test coverage. Learn how to be in control of your test process by stepping up your test automation to the next level.

Embedded development and Internet of Things development is often done on platforms that lack modern software development and test automation tools. The more esoteric or the smaller the target audience, the less likely tool vendors are to create products that directly support the deployment environment. This can make getting started with test automation using older tools that are not as actively supported by vendors can be a challenge that has to be overcome by a team that wants to move toward a Continuous Deployment process.

This session is aimed at people that are trying to adopt agile and continuous delivery with embedded technology, but might be worried that it can’t work in their particular environment due to their industry, technology stack, culture, or regulatory environment.

The Internet is full of insecure applications that cost organizations time and money, while damaging their reputations when their systems are compromised. We need to build secure applications as never before. While at the same time Agile Software Development practices are moving into the mainstream because they offer companies a faster path to getting their software in the hands of their customers. While security and agility may appear to be in natural opposites that don’t mix well, they don’t need to be. Learn how to integrate application security practices into your Agile practices in a way that doesn’t compromise either. Join Tom to explore real-world examples of secure application development practices integrated into the regular cycle of iterative development used in Agile projects. Learn to marry Agile development with application security practices in a way that best leverages the strengths of both.