Information Technology Solution Delivery in Enterprise Environments Going Beyond Sprint Zero. Continuous Delivery to Shift-Left While the DevOps Feedback-Loop, along with finding issues early by moving production-like environments closer to the developer (Shift-Left), are key principles, there is commonly no tangible way of achieving this. In the typically incremental progression of continuous delivery implementations, eventually automation is built to deliver to production, and typically, that is where the story ends.

After over a decade of maintaining the Continuous Delivery Automation Framework, the time has come to pause new features to clean out the closet… or has it? The Pain and Patience of Paying off Debt My desire to expunge the mistakes of the past and refresh with best practice glamour has, like in the commercial world, abruptly encountered reality. Feature demands, hidden defects and day-to-day challenges made me reflect on what I wanted to achieve and what I needed to be working.

This blog is part of the series of Continuous Delivery Automation Framework use cases. Tokenisation of Web Deploy settings file This content has been moved from the generic CDAF Docs material as it distracted from the common concepts. In this example, a ASP.NET solution is build is being performed to create a Web Deploy package. Generic properties can be tokenised in the Web.Release.config. <connectionStrings> <add name="entities" connectionString="metadata=res://*/Models.mydb.csdl|res://*/Models.mydb.ssdl|res://*/Models.mydb.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=%spnDBHost%;initial catalog=%spnDBName%;integrated security=True;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.

This blog is part of the series of Continuous Delivery Automation Framework use cases. Java Build and Deploy using CDAF This content has been moved from the generic CDAF Docs material as it distracted from the common concepts. In this example, the version is automatically incremented by placing a variable in the pom.xml file <?xml version="1.0" encoding="UTF-8"?> .. <artifactId>springboot</artifactId> <groupId>io.cdaf</groupId> <name>Spring Boot Data REST Sample</name> <description>Spring Boot Data REST Sample</description> <version>0.

Shift-Left with CDAF Build Image. Building In Containers Many CI/CD orchestration tools support building in containers, e.g. GitLab & BitBucket Pipelines, for some of these tools, it is the only supported meethod, e.g. CircleCI & Travis. For these tools the CDAF images have been extended to provide a broad range of software development kits and command line utilities. Agent Containers Azure DevOps does not natively support building in containers, however, the Azure DevOps agent is installed on the CDAF Build Image, so one or more containers can be registered and run in Agent Pools or Deployment Groups.

Behavior-driven development in dependent pipelines. Status Quo It is very common for automated tests to be executed from a test developers desktop, namely because it has a browser and can render pages locally. To allow testing on a variety of platforms and browsers, BrowserStack is commonly used, which is great! However, this implies that the tests are being run from source, and are therefore volatile. Execution from a Pipeline With test execution being performed from source, it is a natural progression to use this same method in a pipeline.

Entering Sprint-0 To embed automation into the feature development lifecycle, a pipeline should exist at the earliest possible time, configured to initially “do nothing” at deploy time. Using the CDAF samples for Linux or Windows, an operational pipeline can be created quickly. Enough to make it run Install CDAF for Linux or Windows and seed your solution. At this point you have the bare minimum to produce an executable deployment artefact.

A Containers Journey The article is oriented to an organisation’s systems, be in public or internal, and not to product shipping businesses. Using Kubernetes as the example runtime platform is for demonstration purposes only, and this journey is not specific to any given runtime platform. From software development, testing and runtime environments, there are different points of focus and scale. Commonly, the development viewpoint may not extend beyond docker (or even local), however when function testing the software, a production like environment is necessary, which is when docker-compose provides a declarative mechanism for creating a testable environment, with code that can be reused in the delivery pipeline and shared among team members.

Realisation with Kubernetes and Terraform Cloud This article is an example realisation of the Containers at Scale, A Containers Journey article, and serves as a demonstration of principles. DevOps, as we are all aware, is not a thing, it’s a principle. That being said there are opportunities for material realisation of this principle. Intermediary tools which help exhibit this are Ansible Tower, Puppet Enterprise, Rundeck and Terraform Cloud. With competing desires, i.

Configuration Management and Tokenised Properties Following the Twelve-Factor principle of configuration separation from the artifact, it is common to have developer centric representations of configuration, for example XML, JSON or YAML, and while these are native to developers, they can be obscure to business or operational users. With CDAF being Enterprise oriented, a business centric approach is followed. A single file of tabular properties is more consumable than a group of native language files, i.