Graduating the AL DevOps Academy

2018’s first AL DevOps Academy has now come to an end, culminating in this year’s intake presenting their final project to the team. We’re very excited to announce that all six of the team passed with Merits and Distinctions! 12 weeks seems to have flown by for us, but here’s a little from them about what tools they’ve encountered, what issues they’ve overcome and how they’re planning for future projects.

We caught up with Lily and Danish, two of the graduates from the Academy team at the beginning of the course, you can see what they had to say, here. Now we’re speaking to Zuri and Sikandar for a better insight into the final assessment and life after the Academy.

What was the final assessment and how was it structured?

Sikandar: We were involved on working on the AWS cloud platform product, to design systems in which developers who made alterations to the platform were informed of the catalogue building properly as well as the apps the catalogue is associated with.

The project was split into levels of complexity including 5 steps. The first three were easier tasks to get sorted earlier, allowing you to tackle the final two at a higher level. These were aimed at further improving the product. We were given a week to complete the whole thing.

We adopted agile practices to organise our work, so we used sprint plans and trello boards to split tasks across people who thought they were best suited to specific sections and they could tackle it most efficiently.

Zuri: For the final assessment, we developed tests to see if anything failed. The main aim was getting applications up and running for different platforms, then test check if the applications had indeed come up. For example, to check if apps were actually deployed properly, we set up notifications to slack. Steve (the trainer) actually gave us the mark scheme for this one which really helped us to break down the project. As Sikandar said, the first three steps were pretty much easy.

Monday was broken down into tasks and putting everything into sprint planning principles, from then we had stand-ups twice a day because we had to address if anyone had any blockers or anything because we couldn’t afford to lose any time.

How did you plan for that?

Zuri: The Friday of the week before, Steve gave us the breakdown ‘spec’ which gave us time to think about it and come up with ideas on what tools to use. I wanted to try something new, to test ourselves and see if we could tackle it using something we haven’t used before. We did end up using something we had never talked about with Steve. The technology, AWS Fargate, was only a few weeks old, so the logic was – maybe there’s something here that’s going to make our lives much easier?  

Sikandar: There was a list of possible tech we could have used throughout the project, so for me, it was a case of dividing them up into those that I knew and those that I was more unfamiliar on, so I could look over documentation.

How did you decide on the tools/technologies you were going to use?

Zuri: We had two options to choose from within CodePipeline, either CodeDeploy or CodeCommit. They’re both AWS integrated systems. We decided to go with Jenkins because we weren’t yet as confident with CodeDeploy. We were given a tight time frame, so using familiar tech seemed the best way to utilise the time we had.  

One thing we did have to focus on was keeping the cost as low as possible whilst keeping it as compatible as possible with all other products used for the current product. Having multiple instances running at any one time costs money. With more time to use AWS, we could make it easier to deploy with the product.

Sikandar: Yeah, I think we would do things differently if we had more time, but the basis for these decisions was not having the time to look into the tech we have little to no experience with. Now we’re on the R&D team, it’s something we can explore further.

What problems did you face and how did you overcome them?

Zuri: The main thing was probably debugging shell script. We had a pretty good grasp on what we had to do but that always takes longer than expected. Then there were a few issues at the end towards credentials. With Jenkins, we were all working on our own branches, and at the end when we were bringing everything together we had to coordinate everyone’s credentials and needs into one place: We expected that, but again the time constraints were an issue.

Sikandar: The main blocker we faced was trying to find a balance between gaining experience with using new technologies and sticking to what we were used to and knew well. It’s all well and good trying to learn new tech because that’s one of the points of the Academy, but if it comes at the expense of not being able to deliver on the final product then it’s no good is it?

Which tools/technologies have you found to be the most useful so far?

Sikandar: The entire AWS suite, it’s very user-friendly, and the level of feedback given to the developer as they use it is incredible. For example when any aspect of infrastructure fails to deploy the documentation back is really good. It’s so detailed and caters for all possibilities.

Another one I found great was the use of Jenkins master and worker system, they meant we were able to run off a small relatively low computing power instance; these were connecting to several larger instances whose computing power was able to run all the jobs we needed.

Zuri: Yeah I agree with AWS, also they have really good community support with people posting real examples. So it’s great for research as well. I also found Slave systems really helpful, we had to run tests on about 5 or 6 apps as quickly as possible, so it made sense to run them in parallel to speed things up. Workers can run 2 tests each.

Tell me a bit more about the technologies you’ve learned about overall?

Sikandar: I think the main thing I can say is that we’ve learned at a greater capacity through the academy.

Zuri: The big one for me was when we spent some time with the R&D team. We saw the Linux Academy for ‘DevOpsy’ people and a lot of the things on there we had already learnt and had a good grasp of. I suppose of all the tools, I like command line interface. None of us had ever heard of that before and now it’s how I prefer to work.

Sikandar: Yeah, that is a big thing for me, I was given the option between Web UI or command line interface, and we definitely prefer CLI. Shell scripting as well, we used that throughout the Academy.

What was the most effective learning method you found?

Zuri: Very hands on. We were initially walked through every step we had to do, which was fine at the beginning because it was all so new, but in the second to third week we were given tasks and Steve just let us run with it. He’d be there to help and answer questions, but we could work it out however we wanted.

Sikandar: Being given an outcome and a way to get towards that. From then using any resources we could find, either those given to us on confluence or researching online. I also found the lab sessions to be really useful. Basically just getting on with it and knowing there is help there if we need it.

Zuri: Yeah I agree, especially with things like automation. Without doing it in practice it all seems very abstract, but once you do it, it all becomes quite concrete. I think it further reinforces any steps we need to take in order to automate things in the future.

Is there a project you’re particularly proud of?

Sikandar: The cloud formation assessment. It’s the one where everything seemed to click and we didn’t have any significant blockers taking up huge proportions of our time. That was about the halfway mark. The main tools were AWS and Jenkins but everyone had pretty varied tasks. We were deploying pet clinic using images, tasked with spinning up a virtual machine and then creating an image from that, then deploying the spring boot application.

Zuri: For me, it was probably the last assessment. I feel like everything we learnt, with the agile methodology and everything else all came together without a major disaster. It just flowed really easily.

Do you think you learned to fail?

Sikandar: We’ve become a lot more resilient. It’s definitely been internalised that failing is not a knock on our ability, it’s just all part of the process.

Zuri: A lot of the time when we’re stuck on a problem, we have the best of the best helping us. It’s comforting to know the most experienced people get stuck with the same problems we do. We’re not necessarily doing anything wrong it’s just part of the process. So we shouldn’t get disappointed or discouraged, it’s not a knock on abilities.

Are there any assessments you found most challenging?

Zuri: Yeah, I would say the second to last (four out of five). We were in charge of creating environments, logging all information and monitoring everything. We could use any tech that we’d learned. Since we just finished with Azure, our team decided to use that in order to get more experience with it. The other team chose AWS. I think this project was only the worst because we wasted so much time trying to make it work, we could have done things on the first day using AWS.

Sikandar: Yeah, I was on the same team so I’d have to say the same for the same reasons.

How have you found the support network of senior engineers around you?

Sikandar: It’s been great, everyone is really willing to help out, we don’t feel like a burden. They really try to use their expertise to apply it to a problem we might have.

Zuri: The graduates from last year as well, they come round and ask how we’re doing. If we’ve got any questions they’re happy to help.

What do you think you could offer to one of our clients now?

Sikandar: I think that we’ve got a solid baseline of technologies and abilities to build upon now when we’re working with a client. Even with new technologies, they’re often just variations on what we know, so it becomes a lot easier to pick things up quickly.

Zuri: Yeah, that’s what the Academy teaches, that you are capable of learning things. Being given the tools to go and find things. It’s obviously daunting to go into a new environment, but I know that I’d be able to teach myself whatever was needed.

Sikandar: At the beginning of the academy, Steve put it best. He said the course is designed to give us a ‘toolbox’.

Zuri: That is literally what we have, an army of tools to use.

The graduates have since joined our in-house Research and Development team, progressing their final assessment with more time to get to know new and old tools in greater detail. We’re thrilled to say that within weeks, many of our graduates will already be joining client projects so keep your eye out for more content to come from all of them as they progress through their careers with Automation Logic.

Interested in joining our award-winning academy? Take a look here.

< Back