As a developer, I interact with source control on a daily basis. In addition, as Team Lead for our Plugins group, my job also involves integrating with other source control systems, so I get the opportunity to help our team members when they have questions about usage or setup.
Version control can help provide fail-safe structure and repeatability to developers – and operations people – on their quest for Continuous Delivery. Our goal is to, basically, Version All The Things. This requires structure, discipline, and the right tooling.
Yesterday, I had a great time taking part in our #c9d9 episode on Version Control and Continuous Delivery.
Our team of panelists discussed the ins-and-outs of versioning: what files should be versioned, how does version control affect your CD pipeline, where is version control heading, and more. We even got to vent and share some version control horror stories (it's always helpful - and entertaining - to hear how we're all in the same boat, tackling the same issues, accidentally deleting the same repository ;))
Some interesting takeaways for me:
- We were all pretty much in agreement that you should try to v ersion as much as possible (including artwork, images, and even marketing collateral). In terms of application deployment, you should version everything that ultimately contributes to your application: source code, configuration management scripts and even the build process, testing process and deployment processes.
- As Brian Fox from Sonatype explains, in order for Version Control to be used across the system, we need to find a way to validate we are using the right component version - no matter where it came from. We need to attach the right metadata/fingerprint, verify their integrity and use them appropriately. For example, as Brian explains, successfully restoring from a snapshot is great, but you may not want to go into production without assessing the security vulnerabilities that may have been found since the time the snapshot was created. So even though the snapshot works it may not be advisable to use it directly.
- Melvin Laguren from Macy's mentioned that while versioning goes hand in hand with CD, you should try to avoid making things overly complicated . The set of tools you're using should match and support your pipeline - otherwise you may end up spending more time fighting your infrastructure and working around it instead of focusing on development.
- Perforce's Jonathan Thorpe and our own Anders Wallgren both commented on how we sometimes construct our processes based on the limitations of the tools we have in place, rather than the other way around. As Anders points out, our thought-process should be "This is what we want our process to be, now let's figure out what tools can support our process." That way, we do not get trapped in the "that's what my tool can do, so this is our process" mindset.
On the Next Episode of Continuous Discussions:
Join us on Tuesday, April 7th, at 10am PST , when we'll be talking about DevOps and Lean in Legacy Environments .
This episode will feature:
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.