Augment your knowledge during software modelling sessions: Decision Log
The most important learning during my career is that the act of creating software is a team effort. We can be a one-person team, but there is someone else involved; at least someone to use it.
Why Integration Tests won’t save you… or your software
Did the title tease you? Great, job is done! Today I will tell you my story about Integration Tests; it came after another knowledge share lunch with my pal Kenny.
By this definition an Integration Test is
(…) the phase in software testing in which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready forsystem testing.
Sounds pretty waterfall, right? It is! also, the implementation approaches that I observed creates huge dependencies between teams, coupling the software release process.
Build and secure containers to support your CI/CD pipeline
There are 2 systems in any company that are critical: the payroll system, and the CI/CD system. Why? You may ask…
If the payroll system doesn’t work, people will leave the company and the company (may) face legal problems; the CI/CD system is the gateway to production. If it is down and there is a bug in production, it will affect your business; loss of revenue, loss of customers, loss of money, just to name a few.
Usually, I find these problems regarding the CI/CD tooling:
- Poor Software Lifecycle Management, with outdated software, containing critical vulnerabilities
- Ancient capabilities in the build agents. In extreme cases, frameworks and tools that are no longer supported by the vendors
- Drifting agents. It means that teams had to do some sorcery to get the software build
- Lack of proper isolation between different builds. It means that a build could access to another build files
- Lead teams to upgrade or install a new framework
- Outdated and strict rules mandated by a operations team. Usually from people that outdated heuristics on how software should be developed
Life of a C# Developer: How to build and test an AWS Lambda locally
Today Serverless is a thing. Although everyone can write a blog post about how Serverless run on servers, I share the same visions as Mathias Verraes:
If you want to tweet or blog about how serverless actually runs on servers, let me save you some time: Nobody thinks that serverless doesn't run on servers. Nobody. You're just taking cheap shots at a catchy name.
— Mathias Verraes (@mathiasverraes) May 12, 2018
Given that, I decided to share my developer experience building, testing and deploying AWS Lambda functions in the .NET world. Not a “Hello World” example, but rather a real-world scenario, where some services integrate with each other. Since a Serverless function is a tiny piece of code in a much larger process, how can I test the flow on my development machine?