Automation Journey - episode I | Hands On Programming

This post is the start of the series on why & how we started the travel towards Continuous Integration and Continuous Delivery, about test automation, build and deployment, time management and security …

: Rider and his Steed in the Desert by Jean-Léon Gérôme

Some start

For a while, I’m working as a consultant and advisor. I have seen a lot, but I really can’t share some of it because of some confidentiality. Additionally, I’m not blaming anyone. Please be informed that that information that is included in this blogs post I can talk about.

Sometimes I saw projects in a very good conclusion, in which I had little to do for a parved. Improving just a few things, the optimization I did was just the icing on the cake. However, I often come across projects that are poorly maintained, there is no task automation implemented, most CI/CD do not really exist, and the development resembles the stone age. Such a dead horse in the desert that will not ride any further. Every cloud has a silver lining. There is always room for improvement, improvement and optimization.

The prologue for this series is started in this post

Let’s explain some concepts

At the beginning, we should clarify a few concepts:

Continuous Delivery

is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, without doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.¹

This is a good definition. To talk about CD at all, you need to realize that there is no such thing as a CD without tests, which are actually a safety switch plugged in and they really determine the quality of the product that goes to the customer. Nobody can afford to have software with errors delivered to the market. Quick tests, CI linked together, operating on the principle of a feedback loop, allow for:

catching errors, thus taking care of quality
a quick view of the whole situation
they allow you to make decisions very quickly ship it/stop
fail fast principle

These 4 things allow you to quickly assess the situation, use hot fixes, fixes, in other words, we know what, how and when to deliver. Take the controll …

Of course, we are not there yet, but that is the goal. There is no reason not to achieve this!

Sprint

Scrum Sprint is a repeatable fixed time-box during which a “Done” product of the highest possible value is created. Sprint lies at the core of the Sprint agile methodology and can be thought of as an event which wraps all other Scrum events like Daily Scrums, Scrum Review and Sprint Retrospective. Like all of scrum events, Sprint also has a maximum duration. Usually, a Sprint lasts for one month or less.²

Existing situation

there was no ant autonated mechanism to relese, moust of the relese process was perfom manually
sprint were two weeks each
there was no test process build on side, most testing was performed after deliver the release to prodyuct owner
there was no test environments only some at hock testing bay the way if needed
no build process, some build on developer machine - low haredware resources
no static checks, no dynamic analysis applayed for build process

2 weeks is too long

In the past a was working for a wide rrange of the companies. Some of them still this day usess woterfall methodology, but huge percent of this range work agile. Ane here we have some word calld as sprint. If you are fast enoutgh … ok I just joking. Back to the point. Some of tohous companies work in 6 weeke schedule, some of them 4 or 3. But in this case we have only 2 weeks periode to deliver new release version to the market. Should users get the release version earlier?

In our case, our two-week period is not enough.

working with users around the world where every delay or shortage is immediately visible
two-week sprints are shorter that it appears, you shoudl ask why …
manual regresion testing gets more and more harder to maintaing, espescially when more and more functionallities are delivered
technical debt nd QA debt are visible at first glance
the difficult situation and the stress accompanying the entire project, unfortunately, can lead to burnout

So as you see we must to do somthing about it. Fail-fast …

Reference:

My site is free of ads and trackers. Was this post helpful to you? Why not

Annotations:

https://en.wikipedia.org/wiki/Continuous_delivery ↩
https://en.wikipedia.org/wiki/Scrum_Sprint ↩

Table of contents: