Last month I tried to explore is it possible to improve versions updating process in our project? By improving I mean make it faster or easier. Here are the results.
Challenges
- 21 modules
- more than 13 environments
- on average developers publish about 10 versions per day (of different modules)
- 2 application server technologies: Tomcat and Oracle WebLogic
Process
Before improvement the process of updating version was the following:
- developer makes some changes and publish a new version of module with this changes
- tester logs in into the server of the environment he want to update and download published version
- (this step is only for WebLogic) tester precompiles the downloaded file with bash script
- tester undeploys old version
- tester deploys new version with bash script
- tester change the version number of the module in the versions tracking system
Process improvement options
I saw 2 ways to improve process:
- Start to use some software for deploy automation, for example Chef, Ansible, Bamboo, Jenkins.
- Improve existing scripts, so testers could skip steps 2, 3, 4 and 5.
Problems of first option with new software:
- Chef and Ansible are the easiest one for the beginning, but for the project which already use Atlassian products is more logical to use Bamboo (then you can link version with JIRA issues).
- If still use Chef or Ansible, then basic levels (free of charge) does not meets our requirements, so we need to buy advanced levels. Again, it is not very reasonable when you have free possibility to user Bamboo.
- Bamboo needs to use agents for job execution. In our project we will need about 10 agents, which is quite expensive.
- Any software installation, configuration, maintaining takes too much time and effort.
- The final time and effort of the whole update process for testers is actually the same, as the time with improved script:
- you still need to open the software, which is the same as logging in into the server
- you still need to define environment, module and version, wich is the same, as run the script with parameters
- you still need to change the version number of the module in the version tracking system
So I decided to improve existing scripts. Scripts are general-purpose, so I needed to write only 2 (for Tomcat and WebLogic), which I can copy to any server.
Solution
Now human doesn't need to insert commands by hand and wait for the response of each step, so it saves about 2 minutes (script for many modules update saves even more time). And the process is definitely easier that it was, so the goal is achieved.
Also there was performed one very little change in scripts, which according to the principle of Pareto provides the greatest benefit – colored output. First scripts gave meaningful output, but the whole text was white – it was quite difficult to read it. New scripts give errors in red, success messages in green and process messages (for example 'Downloading the file...') in cyan, so reading of new output takes seconds.
Summary
This post could be my answer on the eternal question 'do testers have to write code?'. For all people who work with computers (including testers) programming is not the goal, but the tool to achieve some goal. The most common example – it's the tool to improve some process. So if you want to be effective in your work you need to use tools for improving your processes and not being able to write some code should not be the reason why you can't perform improving. Of course, you can ask someone else to write some code for you, but again it's way less effective than to write it by yourself. In my opinion, even librarian, who works on computer could write a code, to improve books registration process or something like that.
So, good tester who is looking for options to work effectively should be able to write some code.
следующим шагом мы написали софтинку которую можно держать октрытой и легко переключаться между серверами и версиями, в общем быстрее выходит, только как минус все деградировали и забыли как делается вручную.
ReplyDeleteПереключение между серверами - звучит как слишком много человеко-часов ради слишком маленькой выгоды (в моем случае). Но спасибо за подсказку, когда опять будет возможность/время заниматься ускорением процесса - подумаю об этом.
DeleteА деградация - да, большой минус, молодые работники вообще не представляют как работает Томкат. И как следствие, любая маленькая проблема требует вмешательства старших, что, наоборот, замедляет процесс. Так что общая выгода от подобной автоматизации зависит от того, как часто случаются подобные маленькие проблемы, которые теоретически могли бы и не возникать, если бы молодые делали все в ручную.
AAAAAAAA, я только что написала длинный коммент и потом выбрала что хочу использовать гугл аккаунт и нажала паблишь. и естественно меня отправили логиниться на гугле и потом вернули сюда похерив мой коммент
DeleteПечалька. Пожалуйся Гуглу.
Delete