November 2014 Summaries

Paul Stovell, the founder of Octopus, discusses the transition from using RavenDB to SQL Server for their product, Octopus Deploy. Initially, RavenDB was chosen for its fast development capabilities, allowing rapid iteration, which was essential when building the minimum viable product. However, despite its ease of use during development, RavenDB presented significant challenges in production, primarily due to index/data corruption issues and API/usage errors that led to frequent support calls. These issues often arose from RavenDB's "safe by default" philosophy, which, while intended to prevent unbounded result sets, created unexpected behaviors in production environments. Consequently, Stovell and his team decided to switch to SQL Server for greater reliability and predictability, despite acknowledging that all databases have their shortcomings. He emphasizes that while the problems with RavenDB might partly be due to their implementation, SQL Server's well-known pitfalls offered a more stable production environment. Stovell plans to share further details about the integration of SQL Server in Octopus 3.0 in a subsequent post.

Paul Stovell discusses an issue encountered with Windows Services running under the SYSTEM account, where environment variables behave differently than expected. Typically, user-defined environment variables override machine scope values, but when services run as the SYSTEM account, the %TEMP% variable defaults to C:\Windows\TEMP instead of the user-specific path. This anomaly led to a bug in a pre-release version of Octopus Deploy, where environment variables were supposed to update automatically before each script run without restarting the Tentacle windows service. Stovell speculates that this behavior might be a backward compatibility feature for older Windows Services. He notes that services inherit environment variables from their parent processes, with wininit.exe setting TEMP to C:\Windows\TEMP, and mentions that a patch will be released to address the issue.

Octopus Deploy 2.6, now in pre-release, introduces a range of new features aimed at streamlining deployment processes, with a significant focus on the Lifecycles feature, which allows for enhanced control over the progression and automation of deployments to various environments. Lifecycles enable users to specify deployment sequences, automate releases, and enforce retention policies, offering a robust framework for managing development and production environments. Additionally, the release improves deployment efficiency with features such as parallel step execution, 5x faster package uploads through streaming, and skipping offline machines to avoid deployment interruptions. The update also includes enhancements like SNI support and a refined interface for better project management and visibility, reflecting feedback from users to enhance the overall functionality and user experience of Octopus Deploy.

Paul Stovell's guide demonstrates how to call an executable from PowerShell, emphasizing the ease of passing arguments by using the ampersand (&). He illustrates the process with a C# executable and discusses how PowerShell can handle variables with spaces as single arguments. Stovell highlights the challenges of dynamically adding arguments and suggests using arrays to manage them effectively, showcasing a method that avoids common pitfalls. He also explores an edge case where a single string of arguments behaves differently, depending on how quotes are used, revealing PowerShell's nuanced behavior. Stovell's insights provide practical solutions for executing commands with complex arguments in PowerShell.

Paul Stovell's blog post from November 2014 offers a guide on customizing build numbers in TeamCity for projects with multiple branches, using a branching workflow like GitFlow. He explains how to generate different build numbers for branches such as master, develop, release, and feature branches through the use of PowerShell scripts and TeamCity parameters. The post highlights the importance of dynamically setting build numbers using service messages and adjusting them based on the branch name, ensuring each build remains unique and traceable. This method allows for coherent integration with other tools like OctoPack, where the build number can be used to specify package versions, thereby maintaining consistency across deployment pipelines.