Tags
Best Practices, Build Process, Continous Delivery, Continous Integratation, Release Management Best Practices, Software Delivery
The Process of Packaging/Building Software often used to be OVer-looked and get considered Operational/ In-Consequential … But, With the DevOps Movement and all the Buzz Today… We see a lot of Companies willing to Invest in Technologies related to DevOps and Enforce/Implement Policies that Better Promote Reliable, Repeatable, more frequent Software Releases.
I have been Consulted as a Build and Release Engineer on Different Software Projects, Large scale and Medium. From my Experience, I can definitely say, If there is not too much Ranting, Last minute Aaha moments, Or Not Too Many People Involved in a Release Call, more often that not, That Company has a good Build and Release Practice.
Its one of those things, People Fail to Notice/Appreciate until something is screwed up real bad!
So, Umm.. Here is my take based on my Experience ..
Yes .. I did read the book on Continous Delivery by Jez Humble .. It is a Huge Influence on me too ..
- Developers:
- 1. Take Updates in your Workspace Continously, Commit Frequently and often.
- 2. Merge Frequently
- 3. Own Responsibility for Release Process of your specific Application.
- 4. Be Pro-Active and Collaborate Well with Ops Teams in Fixing Issues, Improving Processes etc
- A Properly Documented, Well Communicated Approach to Branching that takes into Account, the Entire LifeCycle of Project, including Patches After the App goes into Production. A lack of this insight, will bite you back, when you have different customers using different versions of your App each requesting Patches out of their baseline. (Example: Android Project)
- Have a sort of automated mechanisms to detect new branches, (control/manage the madness around forking baselines to avoid merging hell)
- Build Continously, for check-in
- CI “ALL” Branches
- Have Everything in VCS .. No more loose ends or Env specific Gotchas that need manual intervention. Big NO to config files sitting on Env’s, reliance or Build Script or App on Env based Variables etc.
Dont Bloat your App Configs/Properties/Switches to the Level of a “Framework” across multiple files in different packages/locations that we sometimes, need, a Dashboard to monitor. Keep Things Simple, from the Beginning!!
- Have a setup for Gated Check-in’s meaning Bad Stuff wont even make it to the main-line. (compile and run test-cases even b4 merging to VCS)
- Deploy Continously
- Have Proper Automation to have Build Promotion all the way from Dev to Prod based on the Projects Workflow.
- Properly Documented Versioning Standards and clear way to Audit which version is deployed where and whose changes are part of that latest snapshot and their commit ID’s
- The App Stack should always be the same .. from Dev to Prod Env’s – Eg., JDK’s, DB, other 3rd party tools and their versions.
- The Deployment Env’s should be the Same .. from Dev to Prod … includes the OS Versions, their setup, monitoring/logging tools etc.
- The Deployment Scripts should be the same .. from Dev to Prod .. the only difference will be that.. you will SCP the binaries to hundreds of servers parallels and execute app deployments in parallel
- Smoke Test Deployments – use of app’s jetty, in-memory databases like h2 for data, to quickly verify core functionality of App is the new COOL standard
- Keep the Data and Application Separate, you should have abosolutely no need of Data from DB to come up, it can connect to a DB after it comes up to render more content to users.
- HA principles should be applicable even Dev or Pre-prod Env’s, this will greatly improve the Proj Agility during the Dev/QA Cycles. Yes, We can Load-Balance/ use VIP’s or even simply re-direct with Apache in Dev/QA.
- Leverage other tools like Vagrant, Chef etc to modernize Infra and its Management
– Krishna Chaitanya Kurnala