Many engineering and QA professionals are familiar with and lean on the Testing Pyramid made popular by Martin Fowler. Too bad it doesn’t work for in-transformation teams and doesn’t offer hope to teams looking to create change in an organizations’ commitment to drive towards “continuous testing” (especially when everyone wants to fight about tracking coverage levels). This talk will focus on showing what has gone wrong with the testing pyramid and what new model might work better for in-transformation teams.
Specific items this talk will cover:
– What is continuous testing and why is it necessary for a CICD transformation
– What is the testing pyramid and what are its strengths
– What is the testing ice-cream cone and why is it generally bad
– Where does the pyramid model fall short for in-transformation/enterprise teams
– What is a new model that could work better for in-transformation/enterprise teams
Here are some sample articles Stephen wrote on the topic:
Remember Testing is Good. Kind of like those maze movies where they program and brainwash the kids to believe WICKED is good. However in this case Testing is Good, you just have to know how to apply your creative energies and in what doses to where.
Two talks One night; “Deployments before Deployment were cool: How Yik Yak integrated a deployment system in between TravisCI and Kubernetes” by Steve Brunton, and “Deployments are still cool: How Terminus is building a deployment system with CircleCI, GitHub, and Convox” by Brandon Erwin
The DevOpsATL folks are the place to really learn and find other folks and resources.
Update Note: Feb 16, 2017
So I’ve been asking and pondering and researching and found out that Reppard Walker from my buddies over at Manheim had already covered this topic in their Fullstack Meetup. In January 2016 they hosted, Building an Automation CI/CD Appliance using Jenkins and Docker. Bummer I missed it.
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. Its more than just a new process, its got a new philosophy. Continuous Integration is backed by several important principles and practices.
Maintain a single source repository
Automate the build
Make your build self-testing
Every commit should build on an integration machine
Keep the build fast
Test in a clone of the production environment
Make it easy for anyone to get the latest executable
Everyone can see what’s happening
Developers check out code into their private work-spaces.
When done, commit the changes to the repository.
The CI server monitors the repository and checks out changes when they
The CI server builds the system and runs unit and integration tests.
The CI server releases deploy-able artifacts for testing.
The CI server assigns a build label to the version of the code it just built.
The CI server informs the team of the successful build.
If the build or tests fail, the CI server alerts the team.
The team fix the issue at the earliest opportunity.
Continue to continually integrate and test throughout the project.
Check in frequently
Don’t check in broken code
Don’t check in untested code
Don’t check in when the build is broken
Don’t go home after checking in until the system builds
Many teams develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high. In Suits, they have a can-opener… whats your ritual for success?
Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests. Theory goes that by adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software. With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fueling real change in your organization, and turning your release process into a business advantage.
My question is who is using Jenkins?
Update Note: Feb 16, 2017
So I’ve been asking and pondering and researching and found out that Keith Manning from my buddies over at Manheim had already covered this topic in their Fullstack Meetup a year before, well back in 2015. (I still think of 2016 as my releap year, slightly drawn out by two months) Sep 14, 2015 they hosted, Continuous Delivery with Jenkins and the Build Pipeline Plugin. Bummer I missed it.
Use agile practices like you mean it! But How? Pair programming and test driven development are agile productivity practices, which means that using these practices should make your team more productive. Sometimes teams drop these practices because they aren’t seeing the promised benefits, or they find the practices constraining. Paul Daigle over at Manheim is going to talk more about this at today’s Meetup at noon. Gotta get going. His topic is Deliberate Programming: How to use agile practices like you mean it. Always with the testing these guys.
August might be my Angular month. Check out my CodePens. I have been going to Angular Meetups over the past couple of years, and spent a month in the Web Development Immersive class at General Assembly going over Angular, but I have been slightly resistant to Angular2 & TypeScript. Its like Microsoft just had to get their hands on something pure and mess it up. Which is why I left the Microsoft camp years ago when I was a “Master” of ASP classic…. the VBscript stuff. The server-side type programing. And then I went to the MVC mode with Java, Struts and Tiles. However Angular2 and TypeScript ARE here and its something to jump on and at least get familiar with. And that is what Manheim’s Fullstack meetup is all about. Angular2, TypeScript & You is tomorrow, and I am excited about what these guys have to say about it.