The Automation Logic DevOps Academy is a 12-week intensive course taking the top percentile of STEM graduates and guiding them to become Junior DevOps Consultants when they graduate the course. 

They learn a whole range of tools and skills to prepare them and finish the course by splitting into project teams to complete final projects with ‘customers’ from business functions within the company. The teams are expected to tackle these problems as they would with a real client. Starting with ensuring they have fully understood the problem and what is expected of them, then researching the best method of creating a solution while working collaboratively within their teams and having frequent check-ins with the client to ensure they remain on the same page. 

This time around we had three project groups: 

AAA

The team was tasked with creating an end-user-automation tool to review the events surrounding the onboarding and offboarding of engineers. The current system means the office staff have to access data from multiple systems to get an overview of events for an engineer at AL e.g. whether they are new candidates, need new accounts to be set up, whether they have completed their timesheets, if they are being sent to client site, etc. It would be a lot more efficient to be able to access all the information from one simple site/software enabling the use of that information for requirements such as creating new accounts, notifying the office, updating timesheets, etc. 

They decided to create a system that enables any end-user, with or without a technical background, to automate some of their everyday mandatory tasks to keep things running smoothly. Within the short time frame they were given, they managed to assemble an environment that sends variables from Greenhouse (our external hiring system) to Slack with a customisable notification. This use case is helpful to announce a new joiner to the whole company via our internal messaging system allowing the team to welcome them on their first day. The content of the variable can be altered with to suit required data and sent to other services such as AWS in order to create an account.  

Berkshire Associates 

The client requirement this team was given was for a feature that was outwith the scope of the project. They wanted to get AWS information for individual accounts. This information would then be regularly emailed to specified engineers. After much research, they found that adding to that feature would be extremely difficult and would widen the project time scale they’d been given. To their credit, they quickly realised the feature was not possible to add and worked with their client quickly to reset parameters. They had a discussion about alternative routes that could be implemented to meet the client requirements. Instead of going into a meeting saying we are not able to do x, they went in saying that nonetheless, we can do y and z.

As a result, they produced a server that was able to gather metric data from our AWS account and were then able to send automated emails which contained such metrics as well as a link to the grafana graphs that displayed the AWS data. This satisfied the client’s desire for a basic service. They then included three add on services to go above and beyond: real-time currency conversion of the monetary data values, extra warning emails if the AWS values exceeded certain values and – the pièce de résistance – the inclusion of an Alexa query of the data. The client was satisfied that their requirements had been met and even fed back that this technology could be put into practice to be used on some of our client projects. 

Bumble 

The team were asked to design an engineering placement service:  providing a score for how ‘optimal’ our current engineer/project placement is and able to suggest more optimal placements/moves.  Projects and engineers can be tagged with certain attributes such as the postcode they would commute from and technologies they excel in. This data will generate an ‘affinity’ score between an engineer and a project.

They then created a tool where data from both the client and individual engineers is inputted via google forms and auto-transferred to a google sheet. Then the user will run the algorithm script they wrote. The script pulls the data from the spreadsheets and compares the client’s needs to the skills and desires of the engineers. It then sorts the engineers in order of how well they would be suited to the project. It orders the engineers due to their skills match and their affinity match. Their skills match is based on the skills that the client requires and how well the engineer has ranked themselves in that skill. The affinity score is based on how much the engineer has said that they want to work on those skills.

The teams were assessed continually across the 12 weeks, but the final project presentations account for a large part of their grade. This was scored based on things such as: How they understood the project and explained it back to the company, how they worked together and made use of agile techniques and collaboration tools, if they fully understood the client and delivered what was expected of them, and the effort they put into sourcing the best possible solution. 

We’re pleased to say we now have seven Junior DevOps Engineers joining the team who will be continuing to strengthen their skills based on a personalised plan set by renowned academy trainer Steve Shilling with the full support of the team of talented engineers we have here at AL. Congratulations to them all! 

< Back