DevOps
Anyone out there practicing DevOps?
Forum Discussion
william_roe Yes, I am involved in an organization which encorporates CI/ CD/ Agile and Devops practises.
And I also think TestComplete needs to be upgraded to better fullfill Devops requirements. See some of my recent Feature requests
Why?
mgroen2 wrote:william_roe Yes, I am involved in an organization which incorporates CI/ CD/ Agile and Devops practises.
And I also think TestComplete needs to be upgraded to better fullfill Devops requirements. See some of my recent Feature requests
Why?
I had spoken with someone yesterday who mentioned DevOps and I hadn't heard much about it. The company I'm currently working for lacks the commitment to do more than purchased a few token TC and TE licenses and a single server so I doubt I can convince them to move in the direction of DevOps.
william_roe the world is changing rapidly.... and I am not saying all new is good in advance but you have to pick best practices out of the new practices.. and Agile/Devops is one of them.. see what the benefits could be for you or your organization and also beware of the pitfalls of Agile! (look for agile pitfalls, hidden costs of agile)
Hi,
According to my current understanding...
'DevOps', like 'Agile', 'Framework' and other terms that are overused, is too overloaded with the (internal) definitions and this must be clarified on the start before proceeding further.
For example, I think that the initial idea of DevOps was to establish communication between all participants of the software production line, so that, for example, Development is aware about the problems that Support is presented with. Such awareness might help to understand why Support asks for some things and why it is asked that these things are implemented in a certain way which, from Development point of view, might be not ideal. Alternatively, Support becomes more aware about what, why and how is implemented by Development and why not all requests from Support may be implemented in the asked way.
This idea, to me personally, seems to be a logical and reasonable one.
I also met with the (over-improved?) implementation of the above idea when it was required that all members of the given team can do the same work: develop, test, manage environment. To some initial extent this might work. But in a greater extent, I am far not sure that this is the good idea - every job has its specifics and, for example, while developer can create good unit tests, he can be far less aware about the specifics of the functional UI testing or database performance analysis and improvement. For me this looks like the case with the car garage staff: while in general all mechanics are aware about mechanics, engines, electrical part and painting, I never heard about the requirement that all mechanics in the garage must be equally perfect in, say, engine repair and car painting. And do this for both small cars and trucks. (And if I knew such a garage, I'm pretty sure I would not visit it because I do not believe that one can be perfect in such different skills (even despite the fact that they all are about car repair). And if he is not perfect in any given skill, what is the reason for me to ask for his service? )
Just my current vision based on the latest experience...
AlexKaras So true Alex, I totally agree with you...
I have had job interviews as a tester and the interview ended up in discussion about exactly the same: everybody in the team should do "everything", and to me that's incorrect: up to a certain point everybody can do the same tasks but then comes specialities in. And testing is exactly a speciality. It's a discipline. And leave that specific discipline to the best equipped person, the test engineer!
