On May 18th I posted a tweet that made public my intent to find a new job. I’m happy to announce that search is over!
I have accepted an offer at LinkedIn with a tentative start date in the coming weeks.
I have waited to announce this publicly until I was sure there were no roadblocks. It has been a kind of open secret as I haven’t shied away from sharing it with anyone who asked directly.
This blog is to share that news and a little bit about the circumstances around the change.
At least once a week I am either directly asked to @-mentioned into a question about why Invoke-RestMethod and/or ConvertFrom-Json don’t play nice with the pipeline. I decided to put this into a blog post so I can just point people to it in the future.
Note that this blog entry was written while PowerShell 6.0.2 was current and 6.1.0 was on the way. This behavior may change in future versions.
Recently the PowerShell Team published their PowerShell Core 6.1 Roadmap. Several questions have come up about 6.1 plans for Invoke-WebRequest and Invoke-RestMethod. You may have noticed there is no mention of the Web Cmdlets in their roadmap. That is because the majority of the feature work for the cmdlets is being done by yours truly. As I am a community member and not a Microsoft employee, it would make sense that my work is not included in their blog. Anyway, I felt it was a good idea to share what I have in store for the next 6 months.
I should warn that this is more accurately called "Mark Kraus's PowerShell Core 6.1 Web Cmdlets Wish List" rather than a roadmap. I only have 2 features that are pretty much approved. The rest will depend on whether or not the changes actually get accepted. Also, I'm not part of any team working on this. It's just me and the issue queue back log of feature requests and bugs. If your company wants to hire me to work full time on the Web Cmdlets, then hit me up. Otherwise, this is all a side project for me and life happens. So please don't hold me to any deadlines! :)
I’m excited to announce a new feature for Invoke-WebRequest and Invoke-RestMethod that will ship with PowerShell Core 6.1.0: Resume Downloads!
This is a feature that has been requested many times throughout the years and I’m please to say that it will be included in the next release of PowerShell Core. You should be able to preview the feature in 6.1.0-preview.2.
You can se the code changes in PR #6447.
In Part 5 we configured the AWS CodeCommit to trigger the AWS Lambda when a commit is made to the master branch of the repository. Effectively, our CI/CD pipeline is in place. To use it properly, we first need to add a cc2af.yml configuration file. After the configuration file is there, we can push out first Azure Function to our AWS CodeCommit repository and our AWS Lambda will be triggered and start a manual deployment on the Azure Functions Web App.
We will finish out the series in this post with demonstrating an automatic deployment from AWS CodeCommit to Azure Functions and triggering our Azure Function all from PowerShell.
Sorry for the delay between part 4 and 5! I was at the Microsoft MVP Summit this past week and didn’t have time to devote towards updating. This series is nearing completion with just a few more parts to go.
In Part 4 we published the AWS Lambda and created the AWS KMS Key that will be used for encrypting and decrypting secrets. In Part 5 we will configured the AWS CodeCommit repository trigger to invoke the AWS Lambda and encrypt our secrets to store in in the cc2af.yml file.
In Part 3 we successfully made the first glue between Azure Functions and AWS CodeCommit by making it possible to manually trigger the Azure Functions Web App to pull from the AWS CodeCommit repository. Obviously, a manual pull is not ideal. It is certainly not a Continuous Delivery.
In Part 4 we lay the groundwork for the 2nd piece of glue between Azure Functions and AWS CodeCommit. In order to automatically trigger a pull AWS CodeCommit from Azure Functions, we need an AWS Lambda. AWS Lambda and Azure Functions are somewhat analogous. They serve almost identical purposes in their respective clouds. We also need to create a KMS key that will be used for encrypting and decrypting secrets.
In Part 2 we created the Azure Functions Web App and the AWS CodeCommit repository. In Part 3 we will make the initial deployment from AWS CodeCommit to Azure Functions. To do that we need to create an AWS IAM User Account, grant it access to the CodeCommit repository, generate HTTPS Git Credentials for the user, and configure the Azure Functions Web App external git deployment. By the end of this post, we will be able to manually deploy from AWS CodeCommit to Azure Functions on demand. This is a critical step to make automating the process possible.
This part will be short and sweet. I want to keep the relevant pieces together regardless of their length.
In Part 1 I gave an overview of the Peanut Butter and Chocolate Project. In Part 2 I will cover the required PowerShell modules for the deployment, the settings used in the project, authenticating tp Azure and AWS, deploying the Azure Function App, and Deploying the AWS CodeCommit repository. I also demonstrate how to verify the resource deployments with Pester.
As a reminder, you can obtain the project code from https://github.com/markekraus/PeanutButterChocolate
Source: 1981 Reese's Peanut Butter Cup Advertisement
This blog series will cover a Proof of Concept (POC) Project for creating a PowerShell-based Azure Functions CI/CD pipeline where the code is stored in AWS CodeCommit git-based version control system. The pipeline will be created and deployed using Windows PowerShell 5.1. Every step of the pipeline deployment process will be verified with Pester tests. The result of the project will be the ability to push changes to an AWS CodeCommit repository and those changes will be automatically deployed to Azure Functions.
This blog series is targeted at intermediate level PowerShell users and basic PowerShell concepts will not be described in detail. Also, this series will require some basic understanding of both Azure and AWS clouds and their PowerShell based management. Git and C# .NET Core are also leveraged in this project but they will not be covered in depth as this is a PowerShell-centric blog. Readers need only be familiar with basic concepts of git and C#.
Recently the PowerShell Team published their PowerShell Core 6.1 Roadmap. Several questions have come up about 6.1 plans for Invoke-WebRequest and Invoke-RestMethod. You may have noticed there is no mention of the Web Cmdlets in their roadmap. That is because the majority of the feature work for the cmdlets is being done by yours truly. As I am a community member and not a Microsoft employee, it would make sense that my work is not included in their blog. Anyway, I felt it was a good idea to share what I have in store for the next 6 months.
I should warn that this is more accurately called "Mark Kraus's PowerShell Core 6.1 Web Cmdlets Wish List" rather than a roadmap. I only have 2 features that are pretty much approved. The rest will depend on whether or not the changes actually get accepted. Also, I'm not part of any team working on this. It's just me and the issue queue back log of feature requests and bugs. If your company wants to hire me to work full time on the Web Cmdlets, then hit me up. Otherwise, this is all a side project for me and life happens. So please don't hold me to any deadlines! :)
