Automation Journey - episode III
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 …
Sometimes breaks are good especially when you are changing some setup. But ok some time passed, we just want to know to measure. Someone could just talk about KPI because is useful in corporations to measure progress, and this is not a bad idea. On other hand, we want just to know how to measure some progress automatically.
So we started to measure all build, time to build, even for vanilla build (they always are fast … but could be faster). A number of environments are set up every time while building, testing, shipping and killing them while they aren’t needed anymore.
Data science you say … maybe. Just metrics, to use real data science you need more … But we will talk about this later on.
During that time some decisions were made and some points were marked:
- we have some tech debt, especially with products but also with process and some tools …
- there was not so many automated tests created during one sprint
- there was no fully developed acceptance criteria
- infrastructure was simple, too simple to be used, fully used to develop highly scalable infrastructure with continued delivery with short time
- shortage of time - yes time was the real problem, too many tasks to few people
In this organisation everyone we encourage people to take ownership over some topic and also expect that everyone defines his or her role. This is easy, especially when this is a flat structure.
Be patient next episodes in future.
- 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
My site is free of ads and trackers. Was this post helpful to you? Why not