Continuous Testing Integration With CI/CD Pipeline (PNSQC)

Today, I'm taking a walk down memory lane. I'm listening to Junhe Liu describe integrating various automatic tests into the CI/CD pipeline.

It's interesting to think about where we are today compared to 30 years ago when I first came into the tech world. Waterfall development was all that I or anyone knew (we may not have wanted to call it that, or we'd dress it up. Realistically speaking, any given release was a linear process, and each sequence flowed into each other. While I had heard of Agile come the early 2000s, I didn't work on such a team (or one that presented itself as such) until 2011. 

Likewise, it was around the mid-200s that I started hearing the idea of Development and Operations being two great tastes that went better together being discussed ;). Again, it wouldn't be another decade until I saw it in practice but over time, I did indeed start to see this and I was able to participate in it. 

One of the interesting arrangements in the group I was working at (Socialtext), every member of the team had their turn at being the "Pump King". That's a piece of lore that I miss and it is a long story involving an old USB drive that was kept in a toy jack-o-lantern bucket, hence the person who took care of the protective pumpkin became known as the "Pump King" and after everything went online, the name stuck. The key point was that the Pump King was the person responsible for the Jenkins system and making sure that it was working, up to date, and patched when necessary, as well as running it to build and deploy our releases. Every few weeks, it would be my turn to do it as well. 

Thus it was that I was brought into the world of Continuous Delivery and Continuous Deployment, at least in a limited sense (most of the time this was related to staging releases). We actually had a three-tiered release approach. Each developer would deploy to demo machines to test out their code and make sure it worked in a more localized and limited capacity. Merging to the staging branch would trigger a staging build (or the pump king would call one up whenever they felt it warranted, typically at the start of each day. We'd run that and push changes and version numbering to our staging server, and then we'd run our general tests, as well as all the underlying automated tests with the Jenkins process, of which there were a *lot* of them. Finally, due to our service agreements, we would update our production server and then push uploads to customers who opted in to be updated at the same time. We never go to production daily pushes but weekly was more common towards the end of my time on that product.   

It was interesting to get into this mode and I was happy that we were all taught how to do it, not just one and when needed but that all of us were expected to be able to do it at any time. Thus all of us knew how to do it and all of us were expected to do it every time it was our turn to be Pump King.