PowerShell Invoke-SQL out-file cmdlet does write output to file

To get the PowerShell invoke-sqlcmd to output the results to a text file, you need to have a few operators that are not well documented. For the invoke-sqlcmd, there are several articles that show using the PowerShell out-file –filepath cmdlet.
invoke-sqlcmd -inputfile "C:\SQL\MyScriptFile.sql" -serverinstance ".\MyServerName" -database "MyDatabaseName" | out-File -filepath "C:\SQL\SQLResultFile1.txt"

In this case, the out-file cmdlet does not work as expected. Instead, I found using the -Verbose *>> “C:\SQL\SQLResultFile1.txt” produces the output result that I was expecting.
invoke-sqlcmd -inputfile "$script" -serverinstance "$server" -database "$DB" -Verbose *>> "C:\app\SQLResultFile1.txt"

There are a few good articles that I have found while working through this challenge that help out solving the no output mystery.

How to control the output of a QUERIES including the PRINT statement and ERROR massages using PowerShell

PS Invoke-SqlCmd output to file is empty

Technical Scuba Diving and DevOps

One of my hobbies is technical diving. Over the years, I have observed how technical diving and DevOps practices have some common themes. When I started Scuba diving, I had only an idea of what I wanted from this new hobby. I didn’t know all the steps to get there, but I knew the basic steps required of me to achieve my diving goals. I knew I could not just dive to 100 feet underwater in my first or second session. It would take time, training, and iterations of diving to get the skills required to reach the new experience I was looking for. As in DevOps, it’s a journey.

In diving, there is a large amount of trust that needs to be established between the student and the instructor. Without that trust, the learning experience of going underwater is more difficult. This is similar to a software team; a team needs to have trust among the team members. Without that trust, achieving business goals, and exploring new opportunities become more challenging.

As I progressed and got into more technical diving (diving that goes more than 100 feet and with specialized equipment), other patterns that are related to DevOps practices started to emerge. The risk factor for one. In technical diving, the individual needs to evaluate her/his own risk for each dive. The team needs to evaluate the dive and that all the team members have the correct equipment and skill level for the dive. This is not unlike a software team and release practice. I think of these types of practices in the software world as quality checks for a CI/CD pipelines.

Before we enter the water, we check our equipment and team health. In software development, we validate that the code has passed all the requirements and testing before going to production. Failure of these quality checks either in diving or in software can have huge impacts. Luckily a missed quality gate in a CI/CD pipeline doesn’t kill you or one of your team members as it could in technical diving.

I have recognized that Lean practices are also applied to technical diving. Within our dive team, we have an agreement that “Anyone can stop the dive for any reason at any time” This is hard to do at times since it takes hours or even days to get ready for a technical dive. This one rule has saved the team from bad results. When I ignored the rule, I have had some close calls. This agreement within the team is the same principle concept of the Andon Cord in Lean practice.

The ability to pull a release that does not look right does takes courage. Pulling a release can cost teams and the company time and money. But if you can back it up with good data and experience, then the team should trust your decision. That decision could save your company from impacting the customers, saving it from loss of public trust or revenue

We have another saying within the dive team, “All dives are good dive if you can make back to the surface alive and learn from each dive.” The retrospective and reflection on how each team member can improve are key to any team’s success. The awareness of how the team can improve the next dive and how the individual can be a better team member could be a small thing that makes a big difference.

So, what’s the point of all of this? As I look at the maturity of a DevOps team, I ask myself some basic questions that I learn from technical diving.

1.      Does the team member stay current with their training and skills?

2.      Does the team trust each other?

3.      What is the risk factor of the release, and do the team and business understand and are willing to accept the risks?

4.      Are there quality checks in place to make sure that release is ready for production?

5.      Do I have trust and data points to make the Go/NoGo decision for a release?

6.      Does the team learn from each release and improve on the process?

If a DevOps team can answer yes to these 6 questions, then your team is achieving a healthy DevOps maturity level. I do realize there is more to DevOps than these 6 questions. My focus areas are experience, trust, risk management, and lessons learned.

With trust, skills, standardize practices, quality control, and growth mindset, an organization has a great foundation to build a DevOps practice. With these core abilities, a team and individual are able to explore new horizons and push the boundary in a safe, trusted way.