 When I joined the Workload Automation team, I began as a tester but soon after I also became the owner of the build automation process. How do you think we automate the thousands of builds required to produce every release of Workload Automation? With Workload Automation, of course! The entire Workload Automation process is based on DevOps practices: Continuous & Collaborative Development is based on Automated builds and Continuous integration; then the Continuous Testing helps us ensure that the newly developed code works correctly, enabling us to achieve an accelerated frequency of releases, reduce errors and increase transparency towards our customers in the Continuous Release & Deployment perspective. Having said that, I was not yet on the team when we started building Workload Automation using Workload Automation itself but, for me, it was a great experience to became a client of our own product: it was so exciting to find out how even the smallest feature in the dev and test perspective can result in a huge improvement in the daily life of those who work with Workload Automation. So, I decided that I would tell you a bit more about my work and how it changed with the continuous adoption of the latest releases. Every Workload Automation release requires thousands of daily and nightly builds to allow our developers and testers to provide you the best Workload Automation ever. Just a few numbers:
It’s an enormous amount of work, but thanks to Workload Automation we are always able to manage all the planned and unplanned events and to maintain continuous delivery of the product to our team. As an example, a few months ago, we started using pools instead of single agents: this allowed us to dynamically add and remove workstations into the plan and to face different occurrences of workstation unavailability without any changes in our plans. Any maintenance intervention on our build machines is a worry no more! Also the rerun with successors feature introduced with 9.4 FP1 had a great impact on my daily job: it might sometimes happen that a piece of code can break the build on one or more platforms. Before the introduction this feature, to fix every build break, I needed to rerun the job that was directly impacted by the break and all the jobs that depended on it. It was a huge effort for me, especially at the beginning, to remember which jobs depended on which or to follow all the dependencies to find out. Now, with a single click, I can check all the internal and external jobs impacted and directly rerun them all together.  However, my favourite feature is the customizable and persistent layout introduced with the new graphical views. I’ve finally been able to arrange the jobs according to a specific layout that is meaningful to me: the common build jobs are arranged in the central column. On the right side, I have arranged the jobs in a column for each platform in a row for each component; all the optional jobs are placed on the left side. This helps me daily to find out what’s going on at a glance! I’ve loved the new graphical views from the very beginning, and now they’ve become my favourite “workplace” for every monitoring, troubleshooting and recovery action. However, they are not the only features that changed my way of working… and more great improvements are yet to come with the 9.4.0.3. I’ve just tried some of them in advance and I’m so excited... looking forward to tell you more about them in the near future!
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
March 2023
Categories
All
|
RSS Feed