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.
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.
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.
Fullstack, Front-end, buzzword, jargin and more words, but for real, the world keeps spinning. I just got done with my Web Development Immersive class at General Assembly in May, and I am trying to build good looking sites applying my new found front-end skills, and trying to build processes to them, so Grunt, Gulp and all those fit into the pipeline in the correct places. Well the guys over at the Manheim Fullstack Meetup group did their best to throw me for a loop with their Static Code Analysis: Make Your Front-end Development Seamless topic. But HA, I caught most of it, and think I can apply it… if given a team and some time and a project. Ya pizza really helps, but then, so does having the google drive link to the presentation for later reading does as well.
A demonstration of the most popular front-end tools that can help you write reliable, readable code in record time. You’ll see how tools like eslint, sassdoc, and jsdoc provide practical ways to enforce readable and consistent code. Afterwards, we’ll take a look at how more advanced, language altering tools like TypeScript and Flow can radically improve your coding speed and code confidence. Finally, we’ll dive into how all of these tools work at a fundamental level. So come on down and discover the tools that can make your workflow seamless.
Looking at Full Spectrum Testing for Front-end Driven Web Apps is sort of the topic of today’s Meetup. The Full Spectrum: A Look at Testing for Front-end Driven Web Apps, noon at Manheim
First time I met Mike Clement from Greater Sum. Still need to get to know him better; likewise with Rodrigo Martinez and Ali Dalloul, both people to watch over the years.
Funny enough is that when I do a search I find the Full-Spectrum Testing with AngularJS and Karma