When auto_reload option is true, it means when a template file is modified, Twig recompiles the file and then render the content.
Question : Is auto_reload option set to true recommended in production environment?
In my opinion, it should be set to true in production because If i am using GIT and one of my twig template file has new changes, and then i update my production codes using 'git pull', i dont have to clear cache anymore, Twig automatically detects that this template file has been changed and need to recompile it. So when the template file is being rendered, it will be rendered with the most recent changes.
Would anyone agree with me? If not, then what would you recommend?
I don't agree with you :) auto_reload should be set to false in production. Moreover, I don't recommend to do a git pull to do a live update of the production code.
I recommend you to set a deployment mechanism which is safer for your code. This can be as easy as a script console or based on tools such as Capistrano or Deployer.
I know this is an old question, but in case someone stumbles onto it, perhaps a more expanded answer would be useful.
Technically, there is nothing stopping you from using auto_reload = true on production, but one thing: performance. The fact of the matter is that whether you like it or not using any template engine (except PHP itself, since it was designed as such) will incur performance penalty. It may seem minor, yes, but if you are serving thousands of requests per second - they all add up.
When you also add validation and thus recompilation of the cache files (which are actually PHP code), you will get further performance degradation. Again, it's minor by itself, but it can quickly add up. So, Javier is correct saying, that you should use false on PROD, but his reasoning is wrong.
Or maybe just "not entirely correct". GIT is totally OK for deployment, but only if you keep in mind, that it's not really a deployment tool, but rather a version control system (VCS). In a simplified case you will, at least, have different configuration files, for example, with details for database connectivity. Well, you should have different ones for security reasons. And that configuration files should not go to VCS, thus they will be excluded from your deployment, if you are relying only on GIT.
This is a very simple case, but you can much more complex ones, like stuff requiring compilation (TypeScript, SASS/LESS, JS/CSS minification would probably be the simplest ones of those) or just database updates, that you simply can't serve through GIT. And if you do have anything like that - you need to consider something different than GIT.
Oh and, you can also just GIT the cache files resulting from your development, but that would require you to keep generate appropriate pages in Test environment first, so that they are updated.
Related
i have gitlab omnibus, 8.0.4 version, installed on private server, we need to remove access right from reporter to read/pull/download code,
so we dont want reporter to viewer the source code
I think it can be done through editing some file on the server, right?
how can we do it?
Reporter always has read access to files, issues and merge requests. This cannot be altered (and we do not recommend modifying source files since it makes upgrades more difficult).
My suggestion is to create a separate project with only the issue tracker enabled and add the user as a reporter there. Keep the project with source code private.
Danger section ;)
If you really want to modify the code, look in app/models/ability.rb. In the project_report_rules method remove the rights you do not wish 'reporter' to have.
So I'm using Visual Studio 2012, and whenever I create a new project I always leave out the "Add to source control" option, mainly because I don't what it is, what it's purpose is, or if it would be beneficial to me to use it.
I'm developing a rather large library on my own. I plan on making it open source. Is this what source control is for? Reading up online did not help me unfortunately, I'm still desperately confused. Is source control the same as version control too, by the way?
Some clarification would be greatly appreciated.
Thanks!
Alex
Source control (otherwise known as revision control: http://en.wikipedia.org/wiki/Revision_control) is a way in which you can store and manage changes and revisions to your code-base.
Google: SVN, Git, Mercurial and Google Code, GitHub, Bitbucket.
I personally never start a propject (personal or otherwise without it). Also, I like BitBucket (www.Bitbucket.com) for managing my projects. It's free for a single user and they support Git and Mercurial.
Quite simply, source control is a repository where your source code is stored. It's purpose is to provide a storage spot that is separate to the copy that you are currently working with, so you can make changes locally and then submit them back to your source control repository.
Think of it as being like a library - you can get code out, you can return (modified) code to it. It also gets more complex than that - you can use source control to handle multiple versions of the same source, and to merge changes from one copy to another. Additionally most (all) source control systems should provide a mechanism for tracing changes to code (i.e. audit tracking), and a means to "roll back" or revert to a previous version.
There are a variety of source control systems, some of which you install locally and some which you install centrally and access remotely. In all cases the underlying philosophies are mostly the same, although there are some differences around terminology and implementation of features. Source control is considered to be a system that is separate to your editor, your editor then provides a means to specify which source control provider to use and the location of the source control repository.
I have found this
Git Source Control Provider is a plug-in that integrates git with
Visual Studio
According to this, seems like source control = version control
You were asked this when starting a project because it's much easier to setup before you have many messy pieces. Github is a form of version control. An organized place for code to grow.
Version control really shines if you're collaboratively working on a project with many different pieces to it. Source or version control is the process of taking the many different parts that are being worked on simultaneously and bringing them together as a final project.
If you're working on your own it still may be beneficial to practice with, as still holds some value in allowing a process of documentation, and modular pieces being brought together for a final project.
This wonderful post explains many of the benefits of using version control for your pet projects.
Well, there are a number of good reasons:
1. It’s good to be in the habit. Sure, you may be working alone. But in
the future you may not be. Or your “weekend hobby project” might turn
into a popular project with many developers. If anything like that
happens, being in the habit of using source code control will stand
you in good stead.
2. It protects your code. Since your code is stored
in on a server apart from your development machine, you have a backup.
And then, you can even backup the code on the server. Sure, you can
zip it all up any time you want, but you don’t get all the other
benefits I’m listing here.
3. It can save your butt. Sometimes, you
might accidently delete something. You might make mistakes and change
code that you didn’t want changed. You might start off on some crazy
idea when you are feeling a bit saucy, and then regret it. Source
control can save you from all of these by making it a piece of cake to
revert to any previous state. It’s like a really powerful “undo”
feature.
"Source control" refers to the concept of storing all files that make up the source of an application in an (usually online) repository - where one can manage with fine detail exactly what has changed in the source code between versions, manage issues, involve other people with the project, and generally provide a platform to collaboratively manage a project.
The term is usually synonymous with version control - although you can have a repository and not explicitly name versions. Version control in particular just refers to labeling major versions of your project with a hierarchical numbering scheme (1.2.4 etc.)
There are several different tools that implement different kinds of source control. For example, Git is a source control tool that sets lets you manage a project. Github is a web-site that repositories managed with Git are usually stored on. Mercurial is yet another source control tool.
Typically, source control can be complicated to understand, and usually requires significant time studying tutorials. A lot of concepts are unfamiliar to solo programmers who have only worked on small projects. Changes to source code are managed through commits, and different branches of the project can be worked on by multiple people. Changes from separate branches can be merged, and the project can be forked by another user entirely (at least for Git).
Making your library open source is a good idea, and it's not too hard to give it a home on github. I would look into some resources to find out how to set it up.
Wikipedia says:
Revision control, also known as version control and source control
(and an aspect of software configuration management), is the
management of changes to documents, computer programs, large web
sites, and other collections of information. Changes are usually
identified by a number or letter code, termed the "revision number",
"revision level", or simply "revision". For example, an initial set of
files is "revision 1". When the first change is made, the resulting
set is "revision 2", and so on. Each revision is associated with a
timestamp and the person making the change. Revisions can be compared,
restored, and with some types of files, merged.
In simpler terms, source control allows multiple people to work on the same project without everyone clobbering everyone else's changes. Changes to the same file are merged together, and conflicts can be resolved.
It also allows you to keep version history. You can roll back a file to the way it existed at any point in time, as well as maintain different branches of the program; a way to organize groups of changes.
As Si puts it, source (or version) control will save your life 20 times over.
Source control keeps a detailed history of your code. This enables you and any collaborators to:
Review the history of any code
See changes between two versions
Revert any code you just goofed up
Prevent you from losing any code
Discover which changes caused bugs / crashes
Blame whoever messes up your code
Keep an up-to-date backup of all of your code
Even if you're not working collaboratively, source control is so useful when you accidentally delete your code. I speak from experience.
I would recommend using Git or Mercurial, as they allow branching and offer a more isolated workspace for collaborators to experiment without fear of harming any code.
For online collaboration, Github and Bitbucket are great and integrate well with Git and Mercurial, respectively. They also allow you to track collaborators' changes, choose and merge changes into a central repository, and keep a detailed list of issues.
I have a question regarding perforce. I need to setup a scheme where there are 2 versions, a QA and a Production version. I need to be able to submit code, test the change and push it through to production. The development and production versions will be mostly the same, however there are a few differences, such db host names, include paths, etc...
I would also like t have the ability to have personal versions that could be tested before they are pushed to the QA.
Yes, I have to use perforce.
Does anyone know how to set something like this up? This will be on *nix based OS. I would like to write either a bash or Perl script to handle this.
Thanks,
Your help is really appreciated.
Ok so Production is the "Final Destination". You'll have a branch from Production to QA such that when you want to submit from QA to Production you'll do a Reverse Integration. Similarly your devs can have personal branches from QA such that to submit to QA they'll do a Reverse Integration.
Submitted changes can be checked easily in Perforce just by double-clicking the Changelist.
Is there something specific you need help with?
I'll just add that you can maintain divergence by integrating (p4 integ) and then resolving with the -ay (accept yours) option. That gives you merge credit but doesn't actually copy the changes. That way you can tell Perforce that you want to ignore certain changes that shouldn't ever really be merged, and then you won't be bothered with them anymore.
Do you use Subversion while developing a website with drupal ?
I'm not talking about modules development, but websites development (i.e. adding hook functions, modifying template file.. etc)
thanks
Yes.
Anything that's got any kind of ongoing development or is going to change over time should be version controlled.
Even if you're just doing a very small project, the value of having a version history is indesputable, and being able to make changes without worrying about overwriting someone else's updates is priceless.
Yes, its's good keep a SVN repository synced with your local instance.For that purpose you can use Eclipse.
Yes, but we are moving to git in the near future because it offers a better feature set (distributed SCM ftw) and more options for managing our code base (git submodules, stashing, better hook integration, better merging support, rebasing, and so much more). For the time being we've got our repos setup like so:
/trunk
/branches/6.x/1.x/core
/branches/6.x/1.x/sitename.domain.edu
/branches/6.x/1.x/sitename2.domain.edu
/branches/6.x/1.1.x/core
/branches/6.x/1.1.x/sitename.domain.edu
...
/tags/6.x/1.x/core
/tags/6.x/1.x/sitename.domain.edu
/tags/6.x/1.x/sitename2.domain.edu
/tags/6.x/1.1.x/core
/tags/6.x/1.1.x/sitename.domain.edu
...
Each branch is a svn copy of the trunk repo (where we do most of our development) and each tag is a svn copy of it's corresponding branch. The core branch is the primary distro that we distribute to all of our sites that share the university's look and feel, and each subsite is a site with special modules, custom theme, or any other functionality that isn't part of the primary distro. It makes moving between drupal releases a lot easier, but you can start to run into problems merging occasionally. Also you run into performance issues when the repo starts to grow, which is part of the reasoning behind moving to git.
Yes. Version control is critical. Distributed version control systems such as Git, Mercurial, and Bazaar are particularly nice, and let you start committing immediately, without the need to push those changes to a central server.
My Drupal workflow: use Mercurial and its sub-repositories feature to create independent repositories for 1) Drupal + contributed modules, 2) theme, and 3) custom modules. That way, I can clone from a single URL, get my entire project, and be able to track changes to each distinct piece independently.
I've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.
My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.
Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?
You can use a Filtered Source Control Block to exclude certain files from the trigger.
I just posted a bunch about my default build process here which may be of some interest to you: SVN Website Development and Deployment Solution
The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.
Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!