Apprenticeship Program

All professionals around the world need to be trained and software engineers aren't an exception.

Hence, we announce a unique program (and for sure the first in Israel) we are proud to kick off this week: a Software Development Apprenticeship Program.

PicSocut will hire and train apprentices; We will focus (but not limit) on clean code, reading/writing code, clean architecture, BDD, TDD, simple and business oriented designs, tools and best practices. In nutshell, all what you need to become a highly competent software engineer who cares and proud about his profession.

We are looking for couple of candidates to begin the program!

If you feel it's you, please feel free to send us your resume at jobs@picscout.com

Good Luck!

  

Continuous Integration (CI) and Continuous Deployment (CD). Feature Bits

For more than a decade CI (Continuous Integration) helps us to deliver better code in quicker and saver manner. There are a lot of aspects and rules how to do it right and you can find a lot of information on the Internet.

Before sharing with you how things are being done at PicScout we thought it would be a great idea to give an overview of possible solutions for what is common to be called a feature bit.

In this post I will introduce a flavor called “Feature Toggles (Bits)”:

A few words about the CI:

Why do we need it?

Generally, we want:

•  Prevent integration problems, referred to as "integration hell" and stop spending nights while trying to release a new version to production
• Always work on latest code
• Detect problems early and not during integration/deployment
•  Be almost 100% sure about current code
• Sleep good in the night…

How can we do it?

• Commit early – small changes
• Work on main trunk
• Update your code from Code repository at least once a day.
• All commits should be RFD - “Ready for deployment”. This means, all unit/integration/acceptance tests are green. Commits could be executed in regular way or in two-phase (pre-tested) approach.
• Many more…

Okay, let's say we've worked hard to implement CI/CD recommendations.
That's obviously great, but imagine that now we introduce a new piece of code to our code base.

This code could be:

•   Safe. (Could be deployed without affecting various system components)
•   Internal algorithm/behavior was changed.
•   Column or table was created
•  Some internal bug was fixed
•  Dependent
•    Could be deployed only after making changes in other system components

This new code deployment can be done by using “Feature Toggle (Bit)”.

The main idea is: New code should be enabled/disabled using feature bits.

if (FeatureBitSettings.BitEnabled("ScanPdf"))
{
 // enable new behavior
}
else
{
 // old behavior
}

If you develop code, which is part of different components, feature bits should be added everywhere.
(Note: “if” – is one of the code smells, but for sake of save deployment it could be used).

Additionally, new tests with/without feature bits should be added/adjusted.

Feature bits stay in configuration files.

  true
  false

How it should work? Feature bits life cycle:

1.       Develop new code with feature bits.

2.       Test it: with feature bits On/Off.

3.       Set feature bits Off.

4.       Deploy it.

5.       Everything is fine? Enable feature bits to On (by changing configuration) in right order (if there are dependencies between components).

6.       In the case of problems you can do the rollback quickly by setting bits to Off.

7.       After running for some time (days/weeks) code declared safe.

8.       Remove feature bits from the code. Leave only the “On” code.

9.       Deploy it.

10.   Remove redundant feature bits from configuration.

As we might see, feature bits allow us handle different integration/deployment issues quickly and safely.