As Seth Godin knows opportunity cost just went up. Building and delivering software is getting more complicated, so keep your human mind free to focus on the interesting bits and leave the boring, repetitive stuff to the machines.
What’s the best way to do this? Build your CD pipeline first, setup the infrastructure (preferably serverless) from the start and then get into the flow of development. Add more checks and balances as you go. Run automated tests. Deploy to the cloud.
Azure Pipelines supports storing secret variables within the project, either through variable groups or as secret variables.
This is a convenient place to store all those database connection strings and access tokens you need to allow access to external services like JFrog Artifactory or deploy to Azure services such as a Kubernetes cluster or CosmosDB.
Simply enter the secret value, check the padlock and everything is safe right? Well depends what you mean by ‘safe’!
Although Azure Pipelines take pains to obscure the echoing of secrets to the pipeline console and even prevents secret being made available by default to pipeline scripts this does not mean the secrets can’t be still be , how shall we say, obtained.
A pipeline developer who has access to the azure-pipelines.yml can quite easily grab the secret value, echo it to a file, publish that file as a pipeline artifact and then simply download the file from the pipeline console once run.
Well, if you use variable groups to store secret variables for each environment you deploy to, then YES!
Now this may be fine if only admins have access to run the pipelines, but if your azure-pipelines.yml file is embedded within your application source code this in theory means an application developer could change the pipeline definition to reveal production secrets.
Luckily the Azure Pipelines security onion does have a good selection of layers to peel back.
Security should always be concern number zero with any production system and a CD Pipeline that holds the keys to so many precious castles is a core component to protect.
My current previous WordPress hosting with SiteGround costs $20.39 per month.
Amazon Lightsail $3.50 per month for an instance running a WordPress image.
A saving of a couple hundred dollars over the year!
This is a very useful open source tool used internally by Microsoft to validate that best practices are being followed in their Azure ARM templates.
This short post shows how to incorporate the AzSK ARM Template Checker into your Azure YAML Pipeline.
If you want to use a Linux build agent, you can use the PowerShell task to run AzSK.
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
Install-Module AzSK
Import-Module AzSK
Get-AzSKARMTemplateSecurityStatus -ARMTemplatePath $Env:BUILD_SOURCESDIRECTORY/arm-templates
failOnStderr: trueOtherwise if you are using a Windows build agent, you can use the Azure Extension
Imagine we want to produce a Map with each unique word as a key and it’s frequency as the value.
Prior to Java 8 we would have to do something like this:
Map<String, Integer> map = new HashMap<>();
for(String word : words) {
if(map.containsKey(word)) {
int count = map.get(word);
map.put(word, ++count);
} else {
map.put(word, 1);
}
}
However with the map.merge method we can now do:
Map<String, Integer> map = new HashMap<>();;
for(String word : words) {
map.merge(word, 1, Integer::sum);
}
return map;
Pretty nice eh?
Here are some great reasons to stop using email for team communication and instead switch to Slack
package hello;
import io.specto.hoverfly.junit.core.HoverflyConfig;
import io.specto.hoverfly.junit.rule.HoverflyRule;
import org.junit.ClassRule;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.test.web.reactive.server.WebTestClient;
import static io.specto.hoverfly.junit.core.SimulationSource.defaultPath;
@RunWith(SpringRunner.class)
@SpringBootTest(
webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT,
classes = hello.Application.class)
public class IntegrationTests {
@ClassRule
public static HoverflyRule hoverflyRule = HoverflyRule.inSimulationMode(defaultPath("sm9-create-ticket.json"),
HoverflyConfig.localConfigs().asWebServer().proxyPort(8500));
@Autowired
private WebTestClient webClient;
@Test
public void testCreateTicket() {
this.webClient.get().uri("/ticket?query=x").exchange().expectStatus().isOk()
.expectBody(String.class).isEqualTo("Response from HPSM for create ticket");
}
}
Within DevOps the terms Continuous Integration, Continuous Delivery and Continuous Deployment get thrown around a lot. Here is the simplest definition I could come up with to quickly explain each to a non techie like a project manager.
| Continuous Integration | Running unit and other tests on every branch on every commit and merging to master every day |
| Continuous Delivery | As above but each commit CAN be pushed to production |
| Continuous Deployment | As above but each commit IS pushed to production |
This post shows step by step how to deploy your serverless Java AWS Lambas continuously to production. Moving from pull request, merge, build, deploy and finally test.
For our project we are going to assume a standard Maven Java project structure, with Cloudformation and build specification config in the root of the project.
Within the Maven pom.xml file, you must include the lambda core libraries.
The first step in the AWS CodePipeline is to fetch the source from the S3 bucket
Next step in the pipeline, you need to configure a CodeBuild project.
Set the current environment image to aws/codebuild/java:openjdk-8
Use the following buildspec.yml in the root of your project:
After the artifact is built, we now want to create a change set using CloudFormation.
Define your Lambda function using Java (using serverless format), in your Cloudformation config file, placed in the root of your Maven project.
LambaFunctionName:
Type: AWS::Serverless::Function
Properties:
Handler: au.com.nuamedia.camlinpayment.handler.MenuHandler
Runtime: java8
Timeout: 10
MemorySize: 1024
Events:
GetEvent:
Type: Api
Properties:
Path: /menu
Method: get
The ChangeSet can then be executed and the changes automatically rolled out to production safely. Any problems encountered and an automatic rollback occurs.
Congratulations! you now have your Java AWS Lamba functions deploying to production using Continuous Deployment. AWS CodePipeline is easily configurable via the UI and can also be defined as code and stored in version control.
| Type | Duration | Target | Scope | Estimate | Displayed on |
| Epic | Multiple sprints over a few months | Product Owner | High level objective | – | Backlog |
| User Story | Single sprint | End user or customer | Feature level | Story Points | Backlog |
| Task | Few days | Development Team | Assignable to individual | Hours | Agile board |
