Part-1 | Part-2
Hi Folks,
One of my involvement from last two years was to define Dev-Ops for our platform and in it bits and pieces we evolved it to perfection. Today we may have best in class Dev-Ops(Opinionated) model working but our beginning was humble. Writing this blog series to share our model designed for large Sitecore implementation(Even Multi Sitecore Projects).
But before getting into nitty-gritty of Dev-Ops, Let's understand first what is formal definition of it & goals?
Will check upon these goals back & forth as we progress with our series.
Going back to Wikipedia definition, it is clear that there are few stakeholders and few process which make sure that software development and delivery can go hand in hand. Let's discuss stakeholders in context of CMS, usually there are "Developers", "Testers", "Content Authors" and "Deployers".
Developers : People who do the heavy lifting of code and develop features(Usual Sprint Teams). Teams can further classified if project has clear boundaries like who do feature development Vs Hot Fixes, but this or such classification is merely based on scale & complexity of project.
Testers : People who do the testing of release in different testing environment, they could be also external people like business users who want to do User Acceptance testing.
Content Authors : In CMS system major effort goes into content entry or content assembly. Usually such people do interact with only concerned CMS interface but sometime they need to interact with other system for changing things like CSS, JSS ec.,
Deployers : People who click the button and trigger deployment if that button is available. Otherwise getting there hand dirty while manually copy pasting the release to target systems and do various steps in order to make sure that deployment in safe & successful. These people are usually also refereed as IT professionals.
Now we know what are the goals and who are the stakeholders responsible to execute process in order to reach those goals. Now we need to define the process.
Any Dev-Ops process is dependent upon the project, so no single process can become one & only way forward for everyone. For example a small CMS team with limited resource and scope might be happy with decent source control like GitHub and single tool which take care of build and deployment. I have seen and done myself such setup for example GitHub with help of Jenkins or TeamCity combination can do itself everything required out there(Obviously CMS specific tools are counted here). Elsewhere a large project team require different setup like Bitbucket as Source control, Jira Agile for Project Management & Issue Tracking, Jenkins for Build load, Sonar for Code Analysis, ProGet for build repository, Octopus for Deployment.
Point is how much distributed and deeper your Dev-Ops process likely to be depend upon the scale & scope of project or group of projects you want to execute. But process can be largely same even if executed with help of single tool or multiple tools.
In Figure 1.1 Dev-Ops process depicted which started from Jira (Project Management Tool or Agile Management tool) all the way to deployment and monitoring which can trigger incident and circle back to area where these incident can be logged and worked upon by the developers. Each piece is integrated and has a role in overall process. In end of this series will replace this diagram with tools so that it is clear how we do it in end to see larger picture.
Every CMS system required multiple dependencies, for example few could be system dependencies like .NET framework and few could be soft dependencies like extensions or module available for that CMS or other configuration settings which require to be there before your code and content be functional.
So, along with usual Continuous Integration & delivery I will also explain in detail how we can take care of dependency installation in context of CMS systems. We all know deploying your code to existing running environment is straight forward, but installing dependency to that system or preparing a new environment from start is not so straight. Similarly, how to manage dependencies to be used by a project team in day to day development Vs making sure same dependencies exist in server environment.
In order to explain it I will use Sitecore as CMS in further articles, but largely process can be same for other CMS systems too, So watch out for next article.
Hi Folks,
One of my involvement from last two years was to define Dev-Ops for our platform and in it bits and pieces we evolved it to perfection. Today we may have best in class Dev-Ops(Opinionated) model working but our beginning was humble. Writing this blog series to share our model designed for large Sitecore implementation(Even Multi Sitecore Projects).
But before getting into nitty-gritty of Dev-Ops, Let's understand first what is formal definition of it & goals?
"DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes." (Source Wikipedia)Usually Dev-Ops meant different to different people, but for me key goal is to define a end to end process which enabled team to develop and deploy code safely & easily. I can elaborate this line further in following points:
- Ability to release on demand : Team should be focused on Continuous Delivery and the capability of having software always in a releasable state so that when that new feature is ready to go live - it can go live, regardless of where an organization might be in a release cycle. This enabled business release when they like, Predictably, consistently and very fast. In end purpose is to Stop having 'release weekends' - the process becomes like breathing.
- Fail Smart, Recover Fast, Deploy Safely & Consistently : Deployment should not be large block of code and data which replaces every time everything in target environment, it should be small unit which if fails can be recover easily. What you install should be logged so that you know what to recover and before deploying take appropriate backup so that you can return back in time. In end purpose is to reducing the MTTR (Mean Time to Recover/Resolution/Repair - whichever term you prefer).
- Monitor & Measure : Moving to iterative, Agile methodologies enables us to track a feature from inception all the way through to live and measure its cost of travel through the process. Integrating the software manufacturing pipeline and having an effective application monitoring tool that can identify changes at the business transaction level is essential to being able to report back to your stakeholders on the impact of that new piece of code you put into production. Monitoring system where you host application is crucial to identify the issues and mitigate them before they turn into disaster. Over the period of time this monitoring data can be used for further optimization in resources you put to host the application.
Will check upon these goals back & forth as we progress with our series.
Going back to Wikipedia definition, it is clear that there are few stakeholders and few process which make sure that software development and delivery can go hand in hand. Let's discuss stakeholders in context of CMS, usually there are "Developers", "Testers", "Content Authors" and "Deployers".
Developers : People who do the heavy lifting of code and develop features(Usual Sprint Teams). Teams can further classified if project has clear boundaries like who do feature development Vs Hot Fixes, but this or such classification is merely based on scale & complexity of project.
Testers : People who do the testing of release in different testing environment, they could be also external people like business users who want to do User Acceptance testing.
Content Authors : In CMS system major effort goes into content entry or content assembly. Usually such people do interact with only concerned CMS interface but sometime they need to interact with other system for changing things like CSS, JSS ec.,
Deployers : People who click the button and trigger deployment if that button is available. Otherwise getting there hand dirty while manually copy pasting the release to target systems and do various steps in order to make sure that deployment in safe & successful. These people are usually also refereed as IT professionals.
Now we know what are the goals and who are the stakeholders responsible to execute process in order to reach those goals. Now we need to define the process.
Any Dev-Ops process is dependent upon the project, so no single process can become one & only way forward for everyone. For example a small CMS team with limited resource and scope might be happy with decent source control like GitHub and single tool which take care of build and deployment. I have seen and done myself such setup for example GitHub with help of Jenkins or TeamCity combination can do itself everything required out there(Obviously CMS specific tools are counted here). Elsewhere a large project team require different setup like Bitbucket as Source control, Jira Agile for Project Management & Issue Tracking, Jenkins for Build load, Sonar for Code Analysis, ProGet for build repository, Octopus for Deployment.
Point is how much distributed and deeper your Dev-Ops process likely to be depend upon the scale & scope of project or group of projects you want to execute. But process can be largely same even if executed with help of single tool or multiple tools.
 |
| Figure 1.1 |
Every CMS system required multiple dependencies, for example few could be system dependencies like .NET framework and few could be soft dependencies like extensions or module available for that CMS or other configuration settings which require to be there before your code and content be functional.
So, along with usual Continuous Integration & delivery I will also explain in detail how we can take care of dependency installation in context of CMS systems. We all know deploying your code to existing running environment is straight forward, but installing dependency to that system or preparing a new environment from start is not so straight. Similarly, how to manage dependencies to be used by a project team in day to day development Vs making sure same dependencies exist in server environment.
In order to explain it I will use Sitecore as CMS in further articles, but largely process can be same for other CMS systems too, So watch out for next article.
Good post Vishal
ReplyDelete