Is your Sitecore module development and build process ideal?
2016-04-01 | SitecoreI maintain a fairly well used "Field Fallback Module", which was released in June 2012. The code for this module is available on GitHub and it has been setup with a very simple build process that has remain unchanged since day one. The module isn't under heavy development, but there have been a couple bugs reported lately. I took this opportunity to revisit the build and deploy process and see if we couldn't modernize it a bit.
Currently. the steps required to update the module are:
- Clone repo
- Ensure we have Sitecore assemblies as required by readme
branch
Develop and Test- Update the various AssemblyInfo.cs files and TDS projects with the new version number
- Switch VS into the 'Release' configuration
- Build the solution in Visual Studio
- The process takes all 'artifacts' and copies them to the
/release
folder
- The process takes all 'artifacts' and copies them to the
- Commit locally [merge to master]
- Add a Tag to the repo
- Push to GitHub
While this process works just fine I am not happy with the manual steps in 2, 4, 5 and 6. Furthermore, the actual releases are stored in source control, which is not ideal.
Ideally, I want my process to be this:
- Clone repo
branch
Develop and Test- Commit
merge
- Tag the repo
- Push to GitHub
- Automatic build with artifact hosting
So, how can we achieve this? The following posts will outline the steps to get a proper build process around your Sitecore module.
- Private NuGet feed of Sitecore assemblies
- Configuring TDS for hosted builds
- AppVeyor builds with automated versioning and publishing releases to GitHub
Comments