February 2014 Summaries

Octopus Deploy offers robust support for variables that can be scoped to specific machines, environments, and roles, allowing for substitutions in XML and other types of configuration files during deployment. In version 2.3, Octopus extends its variable substitution capabilities to various file types, using a consistent syntax, as demonstrated through a sample application involving a feed monitoring service where server configurations are stored in a JSON file. This process involves using a template file named Config.json.template, which incorporates features like #{each} and #{unless} to dynamically configure server endpoints based on the deployment environment. The deployment feature is straightforward to set up, requiring a list of files for variable substitution and a PowerShell snippet to replace the target file with the template content. This results in an automatically configured JSON file tailored to the specific environment, facilitating seamless deployments.

Octopus Deploy 2.2 introduces several enhancements and new features, including a Script Console for administrators, allowing the execution of ad-hoc administrative tasks using PowerShell across multiple machines with centralized output viewing. This release also offers the ability to define deployment scripts within the Octopus UI, providing flexibility for scenarios where embedding scripts in NuGet packages is impractical, although embedding is generally recommended. Additionally, a full-screen PowerShell editing feature is introduced for improved script editing, and enhancements are made to IIS site creation, allowing users to bind fields on HTTP/HTTPS bindings. The release addresses numerous bug fixes and minor improvements, aiming to streamline deployment processes.

Octopus, an automated deployment tool, bridges the gap in the DevOps continuum by possessing knowledge of both the applications being built by a build server and the endpoints managed by a monitoring service. It provides insights into deployment environments, the composition of applications in terms of Windows Services and IIS websites, and the machines these services are deployed on. Octopus can potentially enhance its functionality by integrating monitoring features that allow users to check whether deployed applications are still operational and to manage their status directly from the Octopus dashboard. This proposed feature, if implemented, would enable users to monitor services, start or stop them as needed, and maintain an audit trail without the need for extensive monitoring systems. The idea is presented as a potential development for 2014, with feedback sought from users on its utility and additional monitoring possibilities.

Octopus Deploy is enhancing its security measures by transitioning to hashed and salted storage for API keys using PBKDF2, similar to its password security approach, to prevent unauthorized access and misuse. Previously, API keys were stored as plain text, a common practice across many web applications, posing a risk if database contents were accessed. Inspired by Amazon Web Services' recent security update, Octopus Deploy version 2.2 will only present API keys once upon generation, requiring users to securely store them independently. This update will also allow users to manage multiple API keys, deactivate compromised or redundant ones, and enhance auditing by recording authentication methods in audit events, ensuring better security and traceability.

Paul Stovell, the founder of Octopus Deploy, discusses the challenges and future plans for integrating Octopus Deploy with Microsoft Team Foundation Server (TFS). Unlike the seamless integration with JetBrains TeamCity, combining TFS and Octopus often requires custom MSBuild scripts and workflow changes, which Stovell aims to simplify. The goal is to enable automatic release creation and deployment with Octopus immediately after a Team Build completes, without necessitating any workflow adjustments. This integration might be achieved by embedding the feature within Octopus or developing an external service to bridge the two platforms. Stovell encourages users of TFS and Octopus to participate in a brief survey to assist in shaping the integration's development.

OctoPack 3.0 introduces significant updates aimed at improving the packaging process for users, particularly those using Team Foundation Server (TFS). The key enhancement is a shift from using $(OutDir) to @(FileWrites) and @(FileWritesShareable) for packaging binaries, which resolves file organization issues in TFS environments. Another major update is the elimination of the need to check OctoPack into version control, aligning with Microsoft.Bcl.Build's approach, and requiring a NuGet package restore prior to building. To address build issues that arise when the server cleans files before builds, a proactive NuGet Package Restore is recommended. In addition to these changes, several bug fixes and new features were introduced, including enhanced version detection and the ability to use custom file settings. These improvements largely stem from community contributions, with the commitment to more actively review submitted pull requests.

Self-service application deployment, as discussed by Paul Stovell, empowers team members to deploy to pre-production environments, reducing reliance on release managers and promoting efficiency. However, for this approach to succeed, trust is crucial, as well as adherence to several key requirements: automation of deployments, consistency across environments, robust auditing and logging for visibility, and a strong permissions system to control access. Stovell shares his experience from working at an investment bank, illustrating how reliance on a singular release manager like "Mike" can create bottlenecks and inefficiencies. He emphasizes that while self-service deployment can enhance team empowerment, it requires a structured approach to maintain trust and ensure successful deployments without compromising production environments.

Octopus Deploy 2.1, released shortly after version 2.0, introduces several enhancements, including a built-in NuGet repository for faster application package management, detailed auditing for better transparency by displaying change diffs in the audit log, and improvements to the variable editor allowing sorting and filtering. The update also enables guest sign-in with read-only access and adds GUI management for multiple instances of Octopus Server and Tentacle, which were previously managed via command line. Additionally, the release includes minor bug fixes and enhancements like project cloning, reflecting the company's ongoing commitment to improving user experience.

Octopus 2.0 introduced a robust REST API that mirrors the capabilities of the UI, allowing users to perform operations programmatically, such as importing variables. This API utilizes VariableSet resources to manage collections of variables, enabling users to GET a VariableSet, make modifications, and PUT it back. These VariableSets are associated with specific projects or releases, ensuring that changes are tracked per release. The process of using the API involves accessing project links to retrieve and modify variables, as demonstrated with the Octopus.Client example provided, which showcases how to add and scope a new variable within a project. The API's structure supports easy mapping of environment names to IDs, facilitating precise scope specifications. This detailed walkthrough aims to enhance understanding of the API's functionality and its application in managing variable sets effectively.

In his article, Paul Stovell discusses the software delivery process for applications developed using compiled languages, emphasizing the decision between building binaries once or prior to each deployment. Building binaries once, according to Stovell, reduces the risk of deployment inconsistencies caused by environmental changes such as updates to libraries, compilers, or operating systems, which can lead to discrepancies between test and production environments. He highlights the importance of deployment automation in enhancing the reliability and frequency of software releases and acknowledges that while building binaries once necessitates artifact storage, it offers the advantage of having easily accessible previous versions for potential rollbacks. Stovell uses the example of differences between .NET framework versions to illustrate the potential pitfalls of compiling before each deployment, suggesting that maintaining consistency through single builds can lead to smoother production deployments.