Getting started to Emencia¶
Welcome to Emencia,
This is an introduction to get started on our structure and technologies where you can find some usefull links and short explanations.
Every Emencia workmates are connected on Slack during worked hours on team emencia-group.
Also you will be given a personal email on @emencia.com domain.
We still keep a safeback on IRC channel #ecs on server irc.freenode.net.
We have an Extranet website for our internal information. You should have been given a new account on Extranet, if not ask for it to someone.
The most important Extranet services are:
- To fill your planning and write your worked hours, extra hours and vacations. Dont forget about it as this is used at the end of each month to calculate your pay slip.
- To communicate on internal stuff and especially there is a thread Emploi du temps > Demande de congé to ask for vacation.
- Contains informations about users, customers, etc.. In the end, most informations should be migrated to the Bazar service.
Probably one of our tools you will use most of the time is our Issue Tracker that you should have been given access to (if not, ask for it).
Once given access with a personal account, you will find all your assigned tickets on a link like this:
Where User is your account username (case sensitive). You should bookmark this so you won’t never lose any ticket.
You can find a quick Tracker tutorial into our Academy site.
We use a Git flow based on branches, merge requests and automatic update deployment.
- Commonly you will never work directly on master branch, instead you will create your own new branch for every task or issues;
- When your work is stable enough to be released, push your branch and go to the gitlab project to create a new Merge request;
- Merge request will trigger a service that will perform some check about code;
- You may wait some minutes before check service validate or not your commits;
- When it’s ok, you can use the Accept merge request button, it will merge your commit into the master branch and perform automatic deployment;
When your work has been merged, you will need to update your local repository to include the merge from master branch, usually with something like this:
git fetch && git rebase origin/master
Only then after you can continue to work else your branch can be broken and futher merge request may be refused or even broke the master branch.
This flow is rarely effective on project created before 2016. In this case, you will still work on your own branch but merge it directly into master before pushing everything. Automatic deployment won’t be available and you will have to ask to Builtex team for integration or production updates.
We mostly develop on Python 2.x with Django. Projects are stored into our Gitlab, some of us may have usefull snippets. And eventually we have a public Github organization where is stored all our public applications repositories.
Almost all projects use Buildout to perform project deployment on multiple environment in a convenient way for Linux and OSX systems.
All our Django projects are using a common structure allready configured for our common used technologies (Apps, Webdesign stuff, Nginx support, Monit support, etc..). Previously we used Epaster (you may see some old projects with it), now deprecated in profit of cookiecutter-djangocms3-buildout.
Default database type for project is Sqlite3 for development and integration environment. And Postgresql for production.
Finally in some rare cases when you need to build static pages without of a Django project, you can see at Optimus that allows you to build pages using Jinja2 templates (almost the same than Django templates) and optionally some Python code.
Please, write some useful comments in your code, think about those ones which could have to fix or change something after you.
Since we are using Django, most of all templating integrations is done with Django templates.
Our Cookiecutter template documentation contains most of all informations you need to install Integration stuff.
Website projects follow the same usual pattern:
- Opening project repository on our Gitlab;
- Creating project structure and first commit using cookiecutter-djangocms3-buildout;
- Developing project into personal local development environment;
- Installing project on an acceptance server (also often called “integration” or “development” or even “recette”) using project integration deployment;
- Validating project with customer;
- Finally installing project on production server using the project production deployment;
During project support time, we follow again these rules starting from acceptance part for each issue.
We never code directly on acceptance server or production server.
Acceptance and production projets installs and updates are managed from people from internal group named Builtex.
- If you mind about writing some documentation, we have emencia-sphinx repository which is installed on http://docs.emencia.net/, you can add new documentation to it using the described procedure in its README;
- We have a Sentry service that is used for some projects;
- During integration you may need of image placeholder like FPOImg or Placehold.it;
- In our Sass sources we are naming colors in variables;
- Damned you need to build a Regex, you can use some help;
- All our documentations, project README, etc.. are written in ReStructuredText syntax, you can use Online reStructuredText editor to valid your document before releasing it;
- Most of projects are using Webfont to embed icons, we have a Professional account on Icomoon service to share all projects webfont, ask for it if needed;
- Also we often use Google fonts for fonts and sometime Typekit (we should have a professional account on this);
- Some workmates are working on MacOSX systems, think about them, they may need to install your projects to do some work;
- Don’t release project with static images that are not optimized, install some tool like pngquant or jpegoptim using conservative options to process your images before to commit;