Behavior, Content, Money – 3 Things you should never give away for free!!!

BCmoney MobileTV

To DevOps or not to DevOps (its no longer an option)

Posted by bcmoney on October 12, 2019 in DevOps with No Comments


No Gravatar

Although I would tend to agree with 6 out of 7 points in the above opinion piece… shipping should not be optional and in DevOps its not a company nor “business” decision rather a delivery team decision (they’re mistaking Agile for DevOps there)… for instance Scrum insists on “potentially shippable” increments each 1-4 week Sprint/cycle, we chose 2-weeks as our timebox, but then the decision is deferred to the Product Owner as to whether or not the company desires releasing whatever has been completed.

7 DevOps Myths Busted
No offense to its author, Sara Miteva (she seems like an ambitious person with a passion for both Marketing & Technology from her recent bootcamps), but just like you would not take Medical advice from a really good painter, one should look to the trenches of IT for technical perspectives and ideas for solutions in terms of both the definition of DevOps, and how to acheive it:

Companies who entrust their delivery teams to build reliable Continuous Delivery & Deployment automated pipelines following the DevOps model that best suits the team, actually achieve single-piece flow (micro-sized, incremental, “non-existent risk” releases) rather than putting arbitrary wait times resulting larger/unpredictable/riskier batch sizes or ill-informed bureaucracy/red-tape in their way (which DORA and similar research initiatives have shown) are arguably > 200x more productive in terms of platform stability and change efficiency (as measured in Lead Times, arguably the most important metric other than not accumulating let alone paying down of Technical Debt):
https://services.google.com/fh/files/misc/state-of-devops-2019.pdf

Sometimes folks removed from the work can reach indecision on whether its safe to proceed so better to remove the “pain of deciding” away and move that decision into the request process not release process, so if its been requested it goes when ready, if no longer needed it gets removed or flagged off….  summary “if its not important enough to ship immediately upon completion, its probably not going to have any noticeable impact on company performance, and so… should we really be working on such things”

As we know sometimes the answer’s still “yes that is worth working on” if only to avoid “Feature Factory-ism” (to make up a term), and of course to take a proactive TechDebt paydown approach whose benefits are the hardest to measure, but who is in a better position to decide those, the team implementing or someone 2-3 degrees removed from the work (or suffering/toil when things inevitably go wrong if TechDebt is allowed to accumulate)…

Some things I think we would pretty much all agree on…
the current code sucks (but “mostly works”)
every line in the entire codebase once started out as a PR at one point or another…  or else it wouldn’t have made it into our git repo
if we had our way, we would change most of that code to be better (readable/maintainble, design patterns, UX/A11Y, Performance, Security, etc)?!

almost anything is better than what we have now…
we’ve all gotten better at coding/reviewing/fixing over the past 4 years
we have a tendency to as Wilson Philips said “Hold On for one more day” and squirrel away code, far too often suffering in silence, leaving big gaps in when the rest of the team can checkout progress and provide feedback
Continuous Integration is more than just an ideal to strive for, its become industry standard practice for a reason… everyone integrates what they’ve got all the time (daily at least, but more frequently is in fact better)
the opposite of “Continuous Integration” is “Sporadic Divergence”
to change the code and make it better, first you need a PR
if a PR is incomplete, we trust the reviewers to flag any of the more concerning imperfections, so that additional things can be improved… should be considered bonus if PR submitter points out some areas themselves they already know need further improving.

SeleniumIDE “.side” JSON parser for “Durable Selectors”, more maintainable Test Automation

Posted by bcmoney on April 27, 2019 in Automated Testing, DevOps with No Comments


No GravatarSelenium is the leading open source Test Automation framework. Its WebDriver specification is in the process of being adopted by all the major browser vendors, with most having fairly complete support at this point. WebDriver is the spec document, language-specific SDK bindings, and associated browser-specific driver implementations that enable you to remotely control a browser in an automated manner. This uses a “selector” in the form of:

  • id – attribute “id” of the element
  • name – attribute “name” of the element
  • css selector – full CSS syntax querySelector like “div#search.find”
  • css path – dotted class names like “.my > .thing > .stuff”
  • xpath – xml path based retrieval like “//html/body/div”
  • linktext – “a” anchor tag text values

Choosing a selector for each “Test Step” in a given “Test Case” enables you to fire “commands” at your browser. Using this recipe we can create and run (record & playback) Selenium tests which automate the repetitive mind-numbing testing steps that a Tester would traditionally carry out manually, such as clicking around within a web application, mobile application or website; entering some data, submitting forms, clicking through E-Commerce flows to make purchases, interacting with specific on-screen elements, etc… all to simulate user behavior with your web/mobile application or website in the “real-world”. This frees up QA Testers for more intellectual work such as Performance Testing to help provide suggestions to speed up the app and support more users, Exploratory Testing “fuzz/negative tests” to try to break the system and find its boundaries by using intentionally wrong inputs, Security/Penetration Testing to identify vulnerabilities, Accessibility Tests to improve support for those with disabilities and regulatory compliance, Usability Tests to improve the UI to help end-users, A/B Tests with Marketing team to improve conversions, etc..

There’s just one catch, creating Selenium tests (and test automation in general) can be seen as a significant investment for most companies, one that certainly not all businesses will agree is worth the upfront cost (or that they’ll even fully understand the value of for that matter). This is a problem in today’s fast-moving marketplaces where if you don’t innovate and move with the speed of the market, you stand a real chance at becoming irrelevant and passed up for more “customer-centered” up and coming competitors. Even large enterprises who once enjoyed long lifetimes as monopolies, oligopolies, or simply “difficult to challenge incumbents” are increasingly seeing competition from all corners. Development teams in all companies are being asked to do more with less, and to keep pace; but how can we possibly move quickly and maintain quality, when all of our testing is manual and acts as a gatekeeper or bottleneck to releases getting out the door? This is what the DevOps series on this blog is meant to address.

What if we had a tool for recording and “playing back” a set of manual steps we’ve carried our one time? Could it be possible to “seed” our test automation this way? In fact, yes this is one possible way, and when it comes to Selenium, then SeleniumIDE for the longest time was the answer. Selenium IDE was historically considered as somewhat of the “black sheep” of the Test Automation industry. You wouldn’t kick it out of your Automated Testing flock (toolkit) completely, it still has useful wool to provide, but you might not be able to sell it as easily to a Dev, Ops or QA team as the “best” long-term solution for their test automation efforts. This became especially true recently as Mozilla’s FireFox team, announced they were deprecating their legacy NSAPI/XUL plugin frameworks in favor of the more standardized and modern W3C’s WebExtensions specification. FireFox being originally the only browser that SeleniumIDE 1.x-2.x was built to work on, this effectively set a ticking clock on the lifetime of SeleniumIDE’s usefulness, and as promised, immediately as FireFox 55 was released, QA engineers relying on SeleniumIDE recorded tests confirmed the death of the legacy test automation tool.

All seemed lost for “record & playback” test automation in Selenium, until Visual Test Automation company Applitools got behind an open source project aimed at a revival of SeleniumIDE. There’s pretty clear benefits to them in having an easy-to-use browser-based automation recording too:

  • it lowers the barrier to Test Automation for most Dev, Ops & QA teams out there (not all of which or all members of which will have coding skills to write a bunch of Selenium scripts by hand)
  • it helps companies seed/bootstrap a suite of Automated Tests where they may be in the unfortunate situation of having absolutely none to start out with
  • it puts Applitools on the map in Developer & QA engineer mindshare by contributing a worthwhile project to the open source community
  • folks who previously didn’t know anything about their company now are more likely to hear about them and at least give them a try
  • it enables companies to quickly get up and running with some recorded Selenium tests, then integrate those tests to Applitools’ visual testing (although of course there’s no requirement to do so, you can just go ahead with basic Test Automation and skip the visual stuff or even roll your own basic visual DIFF tool, a possible topic for a future article)

Whatever their main motivations, their efforts are certainly applauded by myself and many others in the open source & Test Automation communities. Documentation for SeleniumIDE in terms of the commands available can be found here: https://www.seleniumhq.org/selenium-ide/docs/en/introduction/getting-started/

You can download the following flavours of SeleniumIDE:

Installation is easy, but in case you need a walkthrough with screenshots this will take you through the main steps:
https://www.guru99.com/install-selenuim-ide.html

So that’s pretty much all the context you’ll need for why “Record & Playback” has value but if you’re still not convinced, listen to the following podcast and webinars:

Read the rest of this entry »

When Gitflow Stops Being Agile

Posted by bryan on April 20, 2019 in DevOps with No Comments


No Gravatar

NOTE: this is a re-post of an original article by Kevin Brandon which disappeared but needs to be preserved as it changed many teams’ perceptions of Gitflow usage in relation to Agile

If you’re in technology and haven’t been living under a rock you’re aware of Git. If you’re aware of Git then you’re probably aware of Vincent Driesson’s eventful blog “A Successful Git Branching Model” that has since been implemented and widely referred to as Gitflow. Don’t let the title of this blog fool you, I don’t have a beef with Gitflow. Vincent was accurate to claim he had a successful Git Branching Model. It gets you there 99% of the time for the majority of teams. Still, I have found as far as a team’s ability to be agile, the prescribed flow can run you a foul when indecisive chickens come home to roost.

In Agile the chickens (the customers and executive management) can sometimes interfere (that’s life/reality). For the sake of this post, I am speaking to when executive management promises a feature that was demoed and they want it out yesterday. The problem is they don’t like the other feature(s) that were also in the build. They want it now, if not yesterday. You could argue semantics of implementing agile here; but, at this point “Agile” has left the building and we need to be agile in the original definition of the word.  In my experience it is at this point you suck it up and do as you’re told to those whom provide you a paycheck.  So you set off to get an artifact of exactly what the chickens want.

Well, if you have been exercising Gitflow, you had N+1 number of feature branches and of which several have been reviewed and approved into the develop branch. The problem is after that demo, the big chicken in the corner laid and egg and said “LOVE IT” but I don’t like the N-1 other features. Your product owner is crumbling and they are chanting what that chicken wants. Now you are faced with cherry picking commits and analyzing merges with unwanted features.

A successful solution to this problem involves some slight modifications to Gitflow. I don’t know if I can be as so brazen to say maybe Git Flow 2.0? But this has proven itself to work and if it helps the pigs, all the better!

Several big differences here:

  • No notion of a “future feature branch”. Let’s face it, all features are future branches until someone in a higher pay grade blesses it to life. Until then any mitigating/mingling with another feature is a risk of feature entanglement.
  • Master branch is back to being the source of origin. Gitflow made develop a first class citizen. develop really is a place we want to have immediate integration of our features. We want to have immediate feedback of our conflicts and a place to demo.
  • develop in this flow is best to be automatically merged once the feature branch is mergeable and passes all unit tests.
  • Special mitigation branches “develop/proj-1” in orange. Here the feature/Proj-1 had a conflict. Rather than resolving the conflict in the develop branch or feature/proj-1 branch, the mitigation is stored separate for future reference. Once the mitigation is made it is pulled into develop. This is key to keeping your features de-tangled.
  • develop should never be directly updated by anyone other than your CI server.
  • develop can be at any time destroyed and rebuilt from available features.
  • Feature branches are only branched from master, never from develop. This is important again to keep us premature exposure to another feature.
  • Releases are made from approved features… not the develop branch… not integration.

Overall this modification to gitflow provides immediate integration feedback, firewalls CI from the world, keeps features detangled, your code review doesn’t inhibit integration, and lets you create releases from chicken approved features. Now that’s keeping Agile to its original roots of being an adjective!

UPDATE (April 20, 2021): folks have continued to consider more streamlined DevOps code delivery workflows, to the point that Vincent Driesson himself (who coined the term and approach for “gitflow”) has all but disavowed its strict adherence in an Agile setting with his May 2020 update, suggesting consideration of trunk-based development, Enhanced gitlfow and/or further simplified “GitHub feature branch” flows.

Using PGP for Email privacy & security

Posted by bcmoney on April 7, 2018 in DevOps, Security with No Comments


No Gravatar

The following is meant to provide a quick summary and some convenience links to guides on setting up PGP for better privacy and enhanced security of your personal and/or work Email communications.

ProtonMail is one of the leading cloud-based Email providers with PGP built in from the beginning.

Hazards of too much screen time (protecting your eyes as a Developer)

Posted by bcmoney on August 13, 2017 in DevOps, E-Learning with No Comments


No Gravatar

“The future’s so bright… I’ve gotta wear shades”

“I wear my sunglasses at night
So I can, so I can
Keep track of the visions in my eyes”

BC$ = Behavior, Content, Money

The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:

1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.

2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.

3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.

  • Archives