Automation Journey - episode II | Hands On Programming

This post is the continuation 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 …

This is the second part of the series, you can find previuse episode here.

: The Wellesley Grey Arabian Led Through The Desert by Jacques-Laurent Agasse

I could start with how you can create the framework in order to improve certain tasks related to the automatic passage of individual test scenarios. But today’s post isn’t about that. Today’s post is about why the provide needs a system to build the changes that a programmer is able to provide.

From to little cat to tiger

Building changes locally on your own machine is ok until:

it is not a large commercial project
we do not work in a group of several/a dozen or so people
tests are working
we want to be as efficient as possible in what we do
we introduced something called the definition of done
we know what are the benefits of introducing automatic deploys and releases and/or we want to introduce such an approach

So let be clear here. If we are working on a big project then we must use good tools, perform and scale-up.

Wait! What about the following questions?

who’s gonna do the setup? Everyone? One person? Some external advisor or some existing team?
Which tool will we use? Maybee cloud?
What is the definition of done?

None of these questions was really crucial, at least for now …

Some decisions have been made. It was necessary to create some kind of infrastructure, something that would allow you to build changes, test them and provide feedback loops as quickly as possible. Building the infrastructure did not happen immediately. First, a suitable server was delivered, confirmation of individual services, including installation, configuration, setup of appropriate permissions, webhooks, etc.

The first launch made a good impression, it works, it is stable. Build server calmly fulfils its function.

To do anything, you must have resources at your disposal. Whether it is time or people or money, whatever it takes to get the job done. Potential, attention, a clear queue of tasks being prepared. It was, among other things, the build system that was supposed to save time for both developers and give quick feedback on a particular build.

Free the developer’s machines!

So far, we have operated in such a way that most of the code / functionalities were built on programmers’ machines. While we still have a small project at our disposal, everything is fine (despite everything, I recommend configuring it also in small CI projects), in large ones it is unfortunately very bothersome.

Until we have a built server build, unfortunately, we were struggling with the inability to perform further tasks in the sprint. The problem was quite serious:

downtime itself is nothing good

we look forward to trying to work on the next task … sounds lame in itself
no possibility to work on next tasks

programmers’ computers, unfortunately, did not have the appropriate hardware resources at the time of boosting the maximum possibilities of the IDE intended for compilation and bidding of the project
possibility of connecting automatic tests

automatic tests can be run immediately before and while deploying to the test environment
possibility to run unit tests

I don’t think I have to explain it ;)
introduction and definition of the Definition Of Done (DoF)

it good to know when the task is complate

We get a bit more granular, and include a series of manual and automated tests to be completed for all PRs. Though this also relies on other devs and QEs to not approved untested PRs. It's just one quality gate of many though.
— A McCullagh (@AmriMc) October 14, 2021
simplyfile the relase process

one release branch for the sprint, one develop branch, some multi-branch dependencies that are most of the cases require an additional retest. Initially, we would have to get a simple branching model with single and short-living release branches per Sprint
range of test devicese/versions/enviroments

parallel testing on different hardware devices and browsers, cover all (or most of them, more than 90%) financial calculations, which does not depend on the browsers, but how some numbers are displayed and presented …
are we ok?

imagen that version is not release yet has for exaple some critical defects, doues defectsare fixed after a while, then retest should be done, during regresiuons, which moues of it is done manually, another for example three defects are found. We blocked the release, prepoering some another fixes and perform some regression checkes, oa ranity checkes to not allow to produiction shoud down.

This is only one imorovement but it was ciritiacl ot create good feedback loop and start improvement and real progress in automation.

Reference:

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

Table of contents:

From to little cat to tiger

Wait! What about the following questions?

Free the developer’s machines!

downtime itself is nothing good

no possibility to work on next tasks

possibility of connecting automatic tests

possibility to run unit tests

introduction and definition of the Definition Of Done (DoF)

simplyfile the relase process

range of test devicese/versions/enviroments

are we ok?

Reference: