July 2014 Summaries

Paul Stovell describes the process of deploying PHP files onto an IIS Server using Octopus, which relies on NuGet packages for deployment. He begins by packaging PHP files into a NuGet package with the help of the NuGet Package Explorer and uploads it to the internal NuGet repository in Octopus. After creating a project in Octopus and selecting the NuGet Package step, he chooses a Custom Install Directory to deploy files to a pre-existing site setup and utilizes Octopus features like Substitute Variables in Files to manage configuration variables. The deployment is completed successfully, with the PHP files and configuration variables correctly placed on the IIS Server, demonstrating Octopus's capability to manage deployments beyond its typical use with Linux-based systems.

In a blog post dated July 25, 2014, Paul Stovell announced a new feature in version 2.5.4 that simplifies viewing previous deployments within a project overview. This enhancement allows users to click on a "Previous" tab to access past successful deployments for each environment, excluding the currently deployed release to facilitate easier rollbacks. The feature also includes a list showing not only past but also any future deployments, which can be useful when viewing older deployments. This minor update, aimed at improving user experience during deployment rollbacks, reflects Stovell's continuous efforts to enhance the Octopus software he founded with his wife, Sonia, in 2012.

Paul Stovell discusses the evolution of application deployment on Windows servers, highlighting the transition from using a single server for multiple applications to employing virtualization and cloud computing, which allows for multiple virtual servers each running a single application. He explores various tools for managing multiple remote desktop sessions, including Microsoft's updated Remote Desktop client, the open-source mRemoteNG, the commercial RoyalTS, and the actively developed Terminals. Stovell also mentions Octopus Deploy, a tool aimed at reducing reliance on remote desktop sessions by improving deployment processes through enhanced visibility, accountability, and reliability. Additionally, he recommends other tools like Remmina for Linux, CoRD for Mac OS X, and Devolutions Remote Desktop Manager, which centralizes connections and credentials.

Octopus Deploy is planning to add first-class support for Linux deployments by introducing agentless machines that utilize SSH for communication, akin to its existing Windows deployment model. This approach involves setting up SSH-enabled machines in the same manner as Tentacle-running machines, with agentless machines appearing on the Environments page and undergoing typical Octopus tasks like health checks. Authentication methods will include password and key-based options, with private keys stored securely. Deployments will involve uploading compressed packages and using bash scripts for orchestration, while the tentacle command will facilitate variable access and command execution. The system will also support XML configuration transformations and enforce retention policies post-deployment. Octopus aims to remain distro-agnostic, testing mainly on Amazon Linux AMI and Ubuntu Server, and seeks feedback from users to refine its SSH deployment strategy.

Lifecycles in Octopus are a new feature designed to streamline the deployment process by introducing structured phases for automated and manual promotions between environments. Each lifecycle is composed of phases that define specific triggers and rules, such as automatically promoting from development to test environments or requiring manual deployment to production. The feature enables complex deployment scenarios, such as preventing production deployments until successful staging is confirmed or flagging problematic deployments to halt progression. Lifecycles also allow for automatic release creation from NuGet packages, thereby enhancing automation without external integration. Additionally, project groups will now focus solely on organizing projects, as lifecycles will manage environment deployment permissions and retention policies. The introduction of lifecycles is expected to simplify and enhance deployment workflows by providing a more controlled and flexible framework.

ASP.NET websites frequently utilize dynamic compilation, which leads to the accumulation of temporary files in the Temporary ASP.NET files directory, necessitating periodic manual removal to prevent build-up. Users of Octopus Deploy, who often perform continuous integration and frequent releases, can manage this issue using the File System - Clean ASP.NET Temp Files PowerShell script from the Octopus Deploy Library. This script, incorporated into the deployment process, removes directories older than a specified number of days, with parameters set for framework version and retention period. The script safely deletes code generation directories and is recommended to be executed before deployment to minimize downtime, especially in environments with multiple websites. For those seeking to avoid downtime and ensure robust deployments, configuring a custom compilation directory in the web.config file is suggested.

Octopus Deploy introduced a feature called "Channels" in version 3.2, which aims to improve the release creation process for teams working on different branches of code simultaneously. The new feature allows users to define branches with specific rules that dictate which package versions appear during the release creation, solving the issue of manually selecting the correct version from a cluttered list. Branch definitions include a name, applicable steps, a version range using NuGet syntax, and optional tags for filtering, enhancing the experience by simplifying version selection based on branch-specific criteria. The feature is designed to be user-friendly, focusing primarily on the release creation page, and encourages feedback from users to refine its utility.

Octopus Deploy 3.4 introduces machine policies, a feature designed to streamline the management of deployment targets by automatically deleting machines that are no longer available after a specified period. This update addresses the challenges of infrastructure management as it scales, particularly in auto-scaling environments where numerous machines are provisioned and terminated daily. Machine policies are most relevant to Tentacle and SSH deployment targets and can be configured via the Octopus portal, command line, or API. The policy employs health checks to determine machine availability, automatically removing those marked as "Unavailable" beyond the specified duration, thus ensuring Octopus remains synchronized with the underlying infrastructure changes.

Dalmiro Granas' blog post provides guidance for newcomers on integrating Octopus Deploy into a continuous integration (CI) pipeline. It outlines a structured approach divided into three stages: build, deployment, and integration. The build stage focuses on compiling, packaging, and pushing application binaries to a repository. The deployment stage involves setting up and testing the deployment process within Octopus, including creating releases and using the Octopus CLI tool, Octo.exe, for command-line deployments. The integration stage combines the previous stages by automating deployment triggers from the build process. The post emphasizes understanding each tool's role, avoiding common pitfalls, and using plugins or Octo.exe for effective integration, while also encouraging users to consult documentation and support forums for more complex setups.

Paul Stovell discusses the limitations of using traditional continuous integration (CI) servers like TeamCity and Bamboo for deployment tasks, and explains why Octopus Deploy is designed to handle the complexities of deployment more effectively. He highlights that while CI servers are optimized for building, testing, and reporting on code quality, they lack robust deployment features, particularly when dealing with remote deployments and parallel execution on multiple machines. Octopus Deploy addresses these gaps by providing built-in deployment tasks, secure remote execution through its Tentacle agent system, and the ability to manage configurations with variable scopes. Stovell emphasizes that deployment processes often require more nuanced handling of errors and manual interventions than CI servers can offer, underscoring the need for a specialized deployment tool. He concludes that while build and deployment share some scripting aspects, they are fundamentally different processes requiring distinct tools, with Octopus focusing on optimizing deployment tasks.