Have you ever heard the phrase ‘Everything can be automated’?
I have and have often used that phrase. Perhaps it’s not always applicable, but the perspective is valuable when there is an automation challenge. However, just because we *can* automate something, it does not mean we *should* automate it.
Now, my experience is that in enterprise organizations, there often is a lack of automation. For example, requesting an application server through a request process could mean that multiple tasks have to be completed, by different teams through manual activity.
It’s probably clear by now that the 2020 pandemic has turned things upside down, including the way we interact and function within IT, specifically in a DevOps team. We still want to uphold principles and working agreements within the team and pursue growth and maturity, but how to do that while working remotely?
I see two challenges:
A pre-COVID-19 team has the advantage of an already established way of working. There is a team dynamic, and the members know each-others non-verbal signals and behaviour…
“All dev teams should start sharing code!”
I’ve heard this phrase several times, and I always wonder “Why?”. It’s the same kind of narrative when we require developers to use a single pipeline tool: We’re just forcing a concept on people, not considering the individual journey of each team. Furthermore, the “Why” is often skipped and instead the focus is on the implementation.
For instance: “Every team must check-in to a monolithic repository”. I’m not saying a mono-repo is a bad thing, but it feels like the hidden motive is control, which could potentially be driven by fear.
Developing with the microservice pattern in mind brings a lot of advantages, but also some challenges. For instance, in order for clients to dynamically discover a service endpoint (instead of having a static configuration) we’ll need Service Discovery.
Hashicorp Consul is a great tool for Service Discovery, and now AWS has it’s own Service Discovery service, called Cloud Map. I like Cloud Map because it’s cloud-native, it integrates nicely with ECS and EKS and it provides a non-DNS Service Discovery method that can be used to register arbitrary attributes of services, for instance, the Arn of a Lambda function.
This is part 2 of the series ‘Unusual Unit testing’ (to me at least).
In part 1 we’ve created unit tests for Bash scripts with Bats, in this article I’m going to attempt to achieve the same for Windows and Powershell.
If you don’t have a Windows environment, don’t worry, we don’t actually need a Windows system to unit test Powershell scripts, we just need to have Docker Engine installed so we can run our unit tests in a Docker container.
Pester is an awsome test and mock framework for Powershell, with a bunch of testing features like assertions and…
In my work I often see well-intended implementations of CI/CD pipelines that might have functional tests but lack unit testing. This impacts the reliability of the functional testing: since the major difference is white-box vs black-box testing, a functional test might succeed even if some components are failing (for instance due to some internal side effect).
Developers in the Java, Python or Ruby world might be familiar with unit testing using tools like JUnit, PyTest and TestUnit. But what about system administrators that maintain Bash or Powershell scripts? …
If you’re an IT engineer like me and you’ve worked in an enterprise environment, you’ve probably had to deal with ITIL, the ITSM framework (v1 through v3 in particular). In theory, ITIL should have a positive influence on the quality of IT services when the implementation of processes are effective and not overly bureaucratic.
That said, ITIL can feel like a burden sometimes. As an engineer, I am only concerned about executing my change and I’m confident that the result will be successful.
And then there was DevOps, the holy grail, a methodology that can solve all software development and…
DevOps coach, AWS Cloud consultant. People > Processes > Technology.