DevOps Architect at a tech services company with 51-200 employees
Consultant
2018-11-22T10:29:00Z
Nov 22, 2018
As I said above, a tool is just a tool. What you need to do is more along the lines of thinking about how to roll out usage of the tool inside your organization. Rolling it out for a couple of teams is very easy. Rolling it out for people who are eager to change their way of working is very easy as well. If you work in an organization that does not have a long history with hundreds and hundreds of applications and rules and policies to follow, it usually means the employees are free to work in their own way. We benefit a lot from that. But as soon as you need to go Agile and respect regulations, when you have a huge legacy behind you, the tool will be there and will be used, but you first have to break that big monolith and change the way of working. Then you will benefit from using the tool. For continuous testing, we are implementing a solution based on CDD and external tools because we want to deploy an application inside an environment, test it, and automatically promote it to the next one if the quality is met. Unfortunately, today in CDD, we don't have that capacity to integrate the testing yet. I know there is a Dataset Repository coming, but I have never used it. We use CDD for the continuous delivery pipeline and we integrate it with a continuous integration platform like Jenkins. It's needed because we want to be able to deliver faster and with better quality. We want the developers to know the changes they are making in the applications or in the product that they're running in production. They should know all the changes and how to test it with the testers. In a DevOps organization, you want everything on the same page and, in the pipeline, you want to have visibility into what's going on, what is delivered where, and what the quality is. That way, when you deploy up to production, it's kind of a non-event. You are sure that it will work if you have previously deployed everything properly in QA. In terms of tracking user stories and fixes within the release pipeline, we have demonstrated these capabilities in a PoC and in some test environments, but not yet in a production environment. To have it properly tracked, your organization needs to have enough maturity in its Agile processes. We are currently running out "Agilification" at scale, and therefore we need to have the proper squad and tribe organization. We need to properly size and design each feature and story and have the proper state. Currently, for instance, people are not in agreement on what an accepted state for a story is, or what an accepted state for a feature is. Therefore, we have the capability in the tool - we demonstrated it - but today the business still has difficulties tracking the progress of stories and features in Agile Central. Therefore, providing automation in CDD, where we update both systems with CDD, seems too early. But our aim is to do it. We have demonstrated it, we have run it in PoC and it works. But the question is, how can we scale the Agile way of working to an organization of 2,000 people? This is the pain point today. Getting there would be the most important business value because then, everyone - even the business - could track the delivery of business value. That's the plus of the tool. If it could integrate the testing, and by that I mean the quality aspect, it would mean that the product owners and business could release autonomously and have a complete view into the quality of what they release. Then, CDD would become an orchestrator, just executing the delivery of a pipeline. But the goal is to reduce all manual intervention to the minimum. Basically, we would shift-left all activities and control to the business, so that they could track and act on the delivery of that business value. We are delivering something like 140 applications and that needs to increase to more than 350. We have 25 groups or squads of users. Each squad can have between four and eight people, sometimes twelve. So we have something like 150 users. But we don't manage users individually, we manage groups of users. The majority of the teams are DevOps teams, but we still have transversal teams which need to become more DevOps. For that, we have to break the way they work, to split those teams and move them into squads. But then the question comes up about the ownership of what previously belonged to the transversal team. It has to move to the business squad or the product squad. The definition of those products goes alongside the change in the organization. We support both models and we roll out CDD at the same time we roll out the Agilification. We even use CDD to deploy its own plugin. We have multiple instances of CDD, one in Dev, one in QA, and one in Production. We use the Production instance to deploy plugins that are a component of CDD, into our own CDD. In our squad, we also have other applications and we used the same CDD to deploy those same applications. From a customer point of view, the customer comes with a new application. We look at the technology, we automate the technology to deploy that application. It could be a WebSphere application or it could be an Oracle database, etc. We train them on how to use CDD and give them the autonomy to deliver their application, given that we have automated the deployment task and integrated it with the test automation team. That team then provides the test automation capabilities, such as running a performance test or running a load test. That is not our specialty. Our specialty is orchestrating the delivery and deployment and to trigger tests. I know other organizations that have deployed the solution here in Belgium, and we often meet to discuss our progress. Because, like I said, deploying the tool is easy, but using it properly to benefit an Agile-at-scale organization is difficult. It's difficult to "Agile-ify" at scale. We discuss how to do that properly, and how to benefit from the tools, whether it's CDD or Release Automation. They often go together. In addition, customers might have JIRA or Agile Central. I'm lucky, I'm using the three: Agile Central, CDD, and Release Automation. They are quite well integrated. Compared to what I have seen on the market, I would round it up to a nine out of ten. It's the simplicity. It's very simple to use and deploy and deliver. And it works. The reason it doesn't get a ten is that you need knowledge about what you are doing, about the shift in control and responsibilities. People get autonomous and you then have resistance. I don't think it's due to the tool. But it could still be improved maybe on those aspects, by providing more controls or permissions and the like. And the other thing that is missing is the test automation or tracking. But I know it's coming.
Application release automation (ARA) is the process of packaging and deploying an application or software update. ARA goes from development through production. The process, and the tooling that makes it happen, brings together solutions that automate deployment, manage and model environments and coordinate releases. ARA solutions sometimes form part of the broader DevOps process.
When PeerSpot members write about their preferences for Application Release Automation software, the word...
As I said above, a tool is just a tool. What you need to do is more along the lines of thinking about how to roll out usage of the tool inside your organization. Rolling it out for a couple of teams is very easy. Rolling it out for people who are eager to change their way of working is very easy as well. If you work in an organization that does not have a long history with hundreds and hundreds of applications and rules and policies to follow, it usually means the employees are free to work in their own way. We benefit a lot from that. But as soon as you need to go Agile and respect regulations, when you have a huge legacy behind you, the tool will be there and will be used, but you first have to break that big monolith and change the way of working. Then you will benefit from using the tool. For continuous testing, we are implementing a solution based on CDD and external tools because we want to deploy an application inside an environment, test it, and automatically promote it to the next one if the quality is met. Unfortunately, today in CDD, we don't have that capacity to integrate the testing yet. I know there is a Dataset Repository coming, but I have never used it. We use CDD for the continuous delivery pipeline and we integrate it with a continuous integration platform like Jenkins. It's needed because we want to be able to deliver faster and with better quality. We want the developers to know the changes they are making in the applications or in the product that they're running in production. They should know all the changes and how to test it with the testers. In a DevOps organization, you want everything on the same page and, in the pipeline, you want to have visibility into what's going on, what is delivered where, and what the quality is. That way, when you deploy up to production, it's kind of a non-event. You are sure that it will work if you have previously deployed everything properly in QA. In terms of tracking user stories and fixes within the release pipeline, we have demonstrated these capabilities in a PoC and in some test environments, but not yet in a production environment. To have it properly tracked, your organization needs to have enough maturity in its Agile processes. We are currently running out "Agilification" at scale, and therefore we need to have the proper squad and tribe organization. We need to properly size and design each feature and story and have the proper state. Currently, for instance, people are not in agreement on what an accepted state for a story is, or what an accepted state for a feature is. Therefore, we have the capability in the tool - we demonstrated it - but today the business still has difficulties tracking the progress of stories and features in Agile Central. Therefore, providing automation in CDD, where we update both systems with CDD, seems too early. But our aim is to do it. We have demonstrated it, we have run it in PoC and it works. But the question is, how can we scale the Agile way of working to an organization of 2,000 people? This is the pain point today. Getting there would be the most important business value because then, everyone - even the business - could track the delivery of business value. That's the plus of the tool. If it could integrate the testing, and by that I mean the quality aspect, it would mean that the product owners and business could release autonomously and have a complete view into the quality of what they release. Then, CDD would become an orchestrator, just executing the delivery of a pipeline. But the goal is to reduce all manual intervention to the minimum. Basically, we would shift-left all activities and control to the business, so that they could track and act on the delivery of that business value. We are delivering something like 140 applications and that needs to increase to more than 350. We have 25 groups or squads of users. Each squad can have between four and eight people, sometimes twelve. So we have something like 150 users. But we don't manage users individually, we manage groups of users. The majority of the teams are DevOps teams, but we still have transversal teams which need to become more DevOps. For that, we have to break the way they work, to split those teams and move them into squads. But then the question comes up about the ownership of what previously belonged to the transversal team. It has to move to the business squad or the product squad. The definition of those products goes alongside the change in the organization. We support both models and we roll out CDD at the same time we roll out the Agilification. We even use CDD to deploy its own plugin. We have multiple instances of CDD, one in Dev, one in QA, and one in Production. We use the Production instance to deploy plugins that are a component of CDD, into our own CDD. In our squad, we also have other applications and we used the same CDD to deploy those same applications. From a customer point of view, the customer comes with a new application. We look at the technology, we automate the technology to deploy that application. It could be a WebSphere application or it could be an Oracle database, etc. We train them on how to use CDD and give them the autonomy to deliver their application, given that we have automated the deployment task and integrated it with the test automation team. That team then provides the test automation capabilities, such as running a performance test or running a load test. That is not our specialty. Our specialty is orchestrating the delivery and deployment and to trigger tests. I know other organizations that have deployed the solution here in Belgium, and we often meet to discuss our progress. Because, like I said, deploying the tool is easy, but using it properly to benefit an Agile-at-scale organization is difficult. It's difficult to "Agile-ify" at scale. We discuss how to do that properly, and how to benefit from the tools, whether it's CDD or Release Automation. They often go together. In addition, customers might have JIRA or Agile Central. I'm lucky, I'm using the three: Agile Central, CDD, and Release Automation. They are quite well integrated. Compared to what I have seen on the market, I would round it up to a nine out of ten. It's the simplicity. It's very simple to use and deploy and deliver. And it works. The reason it doesn't get a ten is that you need knowledge about what you are doing, about the shift in control and responsibilities. People get autonomous and you then have resistance. I don't think it's due to the tool. But it could still be improved maybe on those aspects, by providing more controls or permissions and the like. And the other thing that is missing is the test automation or tracking. But I know it's coming.
Implementation should focus on Agile and DevOps teams. Plan it to gradually create a scalable organization.
Make sure you understand your firewall environment and decide up-front if you are using CDD or RA for orchestration.