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.
Table of contents:
- From to little cat to tiger
- Wait! What about the following questions?
- Free the developer’s machines!
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.
- Starting point - prologue
- Automation Journey - episode I
- Automation Journey - episode II
- Automation Journey - episode III
- Automation Journey - episode IV
- Automation Journey - episode V
- Automation Journey - episode VI
- Automation Journey - episode VII
- Automation Journey - episode VIII
- DevOps - why you should care?
- A few words about automation
- The Wellesley Grey Arabian Led Through The Desert (Oil on Canvas), by Jacques-Laurent Agasse